セキュリティデバイスにおけるセントラルポイントアーキテクチャの概要

中央点(CP)アーキテクチャには、ロードバランシングとトラフィック識別(グローバルセッションマッチング)という2つの基本的なフロー機能があります。このトピックで説明したように、中心点アーキテクチャは、すべてのセッション配信とセッションマッチングが中央点によって実行される中心モード、またはサービス処理ユニット(SPU)の一部が中心点機能の実行に専念する混合モードのいずれかで実装されます。

中心点の主な機能は、セッション処理を SPU の 1 つに委任することです。セッションがまだ確立されていない場合、中央ポイントは、ロードバランシング基準に基づいて、フローのセッションを確立するための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シリーズファイアウォールはサポートされなくなりました。	CPライト 手記： NG-SPC は、混合モードを廃止します。

中央ポイントは、セッションの一致時にパケットをサービス処理ユニット(SPU)に転送するか、パケットが既存のセッションと一致しない場合は、セキュリティ処理のためにトラフィックをSPUに分散します。中心点アーキテクチャーは CP 中心モードで実装され、すべてのセッション配信とセッションマッチングは CP またはコンボ・モードによって実行されます

一部のSRXシリーズファイアウォールでは、SPU全体を中央点機能専用にすることはできませんが、SPUの一定割合は中央点機能に自動的に割り当てられ、残りは通常のフロー処理に割り当てられます。SPU が通常のフロー処理と同様に中心点の機能を実行する場合、それは組み合わせまたは mixed, モードであると言われます。

中央ポイント機能専用の SPU の割合は、デバイス内の SPU の数によって異なります。SRXシリーズファイアウォールでは、SPUの数に基づいて、小の中心点、中程度の中心点、大の中心点の3つのモードを使用できます。

スモール中心点モードでは、SPU のごく一部が中心点機能専用になり、残りが通常のフロー処理専用になります。中程度の中心点モードでは、SPU は中心点機能と通常フロー処理のためにほぼ均等に共有されます。大規模中心点モードでは、SPU 全体が中心点機能専用になります。混合モードでは、中央ポイントと SPU が同じ負荷分散スレッド(LBT)とパケット順序スレッド(POT)インフラストラクチャを共有します。

このトピックは、以下のセクションで構成されています。

• 混合モードでの負荷分散
• 混合モードでの処理能力とメモリの共有

Junos OS リリース 15.1X49-D30 および Junos OS リリース 17.3R1 以降、SRX5000シリーズデバイスでは、より高い接続数/秒(cps)を処理できるように中央ポイント アーキテクチャが強化されています。新しいセントラル ポイント アーキテクチャでは、セッション管理機能リストを SPU(サービス処理ユニット)にオフロードすることで、データパケットが中央ポイントを通過するのを防ぎます。そのため、データパケットは中央点を介さずに、ネットワーク処理ユニットからSPUに直接転送されます。

中心点アーキテクチャは、アプリケーションの中心点と分散中心点の 2 つのモジュールに分かれています。アプリケーションの中央点はグローバルリソース管理とロードバランシングを担当し、分散中央点はトラフィックの識別(グローバルセッションマッチング)を担当します。アプリケーションの中央ポイント機能は専用の中央ポイント SPU で実行され、分散された中央ポイント機能は残りの SPU に分散されます。これで、中央ポイント セッションは専用の中央ポイント SPU ではなく、他のフロー SPU に分散された中央ポイントになります。

手記：

SRX5000シリーズの中心点は、アプリケーションの中心点、または分散中心点、あるいはその両方を指し、グローバルリソース管理およびロードバランシングに関しては、アプリケーションの中心点を指し、トラフィック識別およびセッション管理に関しては、分散中心点(SPUと呼ばれることもあります)を指します。

手記：

SNMPログとSNMPトラップは、レート制限のある中央ポイントによって生成されました。これで、SNMP ログと SNMP トラップが SPU または中央ポイントによって生成されます。SPU が複数あるため、生成される SNMP ログとトラップの数が多くなります。デバイスの 1 秒あたりの接続数(CPS)を確認するには、 SNMP MIB walk nxJsNodeSessionCreationPerSecond コマンドを実行します。SNMP ポーリング メカニズムは、過去 96 秒間の平均 CPS 数に基づいて CPS 値を計算します。したがって、CPSが一定でない場合、報告されたCPSの数は不正確です。

SRX5400、SRX5600、および SRX5800 デバイスでサポートされている中央ポイント アーキテクチャは、GTP-C メッセージ レート制限に対処するように強化され、ゲートウェイ GPRS サポート ノード(GGSN)を GTP-C メッセージ フラッドから保護し、SGSN ハンドオーバー中の GTP-C パケット ドロップの問題を防止し、トンネル エンドポイント識別子(TEID)ベースのハッシュ配信に切り替えることで、GGSN と SGSN のペアで処理された GTP-U トラフィックをすべての SPU で分散します。 enable-gtpu-distribution コマンドを使用して、GTP-Uセッション配信を有効または無効にします。デフォルトでは、 enable-gtpu-distribution コマンドは無効になっています。

GTP/SCTP 負荷分散の問題を解決するために、フロー セッションへの接続タグ タプルが導入されました。分散CP(DCP)セッションとSPUセッションを含むすべてのセッションは、接続タグに対応するように変更されます。セッション作成には、src-ip、dst-ip、src-port、dst-port、protocol、session-token、connection tag のタプルがあります。

GTP ALG では、GGSN IP アドレスをハッシュして GTP-C セッションを修正する必要があります。最初のパケットの方向が不確かな場合、GTP ALG は GTP-C セッションの作成を拒否し、パケットのドロップを引き起こします。GTP-C パケットがドロップされるのを防ぐために、新しいフロー セッションが作成され、GGSN または SGSN の方向が決定されていない場合でも、GTP-C トラフィックの通過が許可されます。その後、フロー セッションを作成し、古いセッションをエージング アウトするために、正しい SPU を使用して GGSN IP が特定されます。古いセッションにヒットする断続的なパケットは、新しいSPUに転送され、新しいセッションで処理されます。

ロードバランシングの問題に対処するため、タグベースのハッシュ分散を使用して、すべての SPU 間で GTP-U/SCTP トラフィックを均等に分散します。GTP-U および SCTP セッションを一意に識別する 32 ビット接続タグが導入されました。GTP-U の接続タグは TEID で、SCTP の接続タグは vTag です。デフォルトの接続タグは 0 です。接続タグは、セッションで使用されない場合、0のままです。フローは GTP-U/SCTP セッションの接続タグを決定し、接続タグをハッシュ化して配信します。

SCTP アソシエーションは、2 つの SCTP エンドポイント間の接続です。各SCTPエンドポイントは、タグとのアソシエーションを識別します。アソシエーション設定(4ウェイハンドシェイク)中に、2つのSCTPエンドポイントはパケット受信のために独自のタグを交換します。4 ウェイ ハンドシェイク中、INIT/INIT-ACK の受信者は itag の値を記録し、このアソシエーション内で送信するすべての SCTP パケットの vtag フィールドに配置します。次に、ピアは vtag を使用してこのパケットの送信者を検証します。

CP-Lite の後に作成されたフロー セッションは、以下のとおりです。

SPU がハッシュ(タグ)によって選択され、クライアントからサーバーへのトラフィックはハッシュ(tagB)SPU で処理され、ハッシュ(tagA)SPU に転送されます。サーバーからクライアントへのトラフィックは、ハッシュ(tagA)SPU で直接処理されます。

1. INIT パケット受信後、ハッシュ(tagA)SPU で:

   DCP セッション A1: client=> server, SCTP, Conn ID: 0x0;

   セッション A1: client=> server, SCTP, Conn ID: 0x0;

   ハッシュ(tagB)SPU:セッションなし。

2. INIT-ACK パケット受信後、ハッシュ(tagA)SPU で:

   DCP セッション A1: client=> server, SCTP, Conn ID: 0x0;

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

   セッション A1: client=> server, SCTP, Conn ID: 0x0;

   セッション A2: server => client, SCTP, Conn ID: tagA;

   ハッシュ(tagB)SPU:セッションなし。

3. COOKIE-ECHO パケット受信後、ハッシュ(tagA)SPU で:

   DCP セッション A1: client=> server, SCTP, Conn ID: 0x0;

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

   セッション A1: client=> server, SCTP, Conn ID: 0x0;

   セッション A2: server => client, SCTP, Conn ID: tagA;

   セッション A3: client=> server, SCTP, Conn ID: tagB;

   ハッシュ(tagB)SPU上:

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

4. COOKIE-ACK パケットを受信した後、フロー セッションに変更はありません。

5. ハンドシェイクが成功すると、すべてのパスでHEARBEATが送信されます。