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

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

中央点の主な機能は、セッション処理をSPUの1つに委任することです。セッションがまだ確立されていない場合、中央点は負荷分散基準に基づいて、フローのセッションを確立するSPUを選択します。セッションがすでに存在する場合、中央点はそのフローのパケットをそれをホストするSPUに転送します。また、NPUが失敗した場合は、パケットを正しいSPUにリダイレクトします。

中央点は、特定のセッションの所有者SPUに関する情報を含むグローバルセッションテーブルを維持します。これは、システム全体の中央リポジトリおよびリソースマネージャーとして機能します。

SRXシリーズファイアウォールタイプとJunos OSリリースの組み合わせによって、サポートされるモードが決まります。

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

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

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

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

このトピックでは、次のセクションについて説明します。

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

新しい中央点アーキテクチャは、セッション管理機能リストをサービス処理ユニット(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メッセージのレート制限に対処するように拡張されており、GTP-CメッセージフラッドからゲートウェイGPRSサポートノード(GGSN)を保護し、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、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はハッシュ(タグ)によって選択され、クライアントからサーバーへのトラフィックはハッシュ(タグB)SPUで処理され、その後ハッシュ(タグA)SPUに転送されます。サーバーからクライアントへのトラフィックは、ハッシュ(tagA)SPUで直接処理されます。

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

   DCPセッションA1:クライアント=>サーバー、SCTP、Conn ID:0x0;

   セッションA1:クライアント=>サーバー、SCTP、Conn ID:0x0;

   オンハッシュ(タグB)SPU:セッションなし。

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

   DCPセッションA1:クライアント=>サーバー、SCTP、Conn ID:0x0;

   DCPセッションA2:サーバー=>クライアント、SCTP、Conn ID:tagA;

   セッションA1:クライアント=>サーバー、SCTP、Conn ID:0x0;

   セッションA2:サーバー=>クライアント、SCTP、Conn ID:tagA;

   オンハッシュ(タグB)SPU:セッションなし。

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

   DCPセッションA1:クライアント=>サーバー、SCTP、Conn ID:0x0;

   DCPセッションA2:サーバー=>クライアント、SCTP、Conn ID:tagA;

   セッションA1:クライアント=>サーバー、SCTP、Conn ID:0x0;

   セッションA2:サーバー=>クライアント、SCTP、Conn ID:tagA;

   セッションA3:クライアント=>サーバー、SCTP、Conn ID:tagB;

   オンハッシュ(tagB)SPU:

   DCPセッション:クライアント=>サーバー、SCTP、Conn ID:タグB

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

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