Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

GGSN の概要

ゲートウェイ GPRS サポート ノード(GGSN)は、モバイル ユーザーから受信する受信データ トラフィックをサービス ゲートウェイ GPRS サポート ノード(SGSN)を介して変換し、関連ネットワークに転送します。また、その逆も同様です。GGSN と SGSN は共に GPRS サポート ノード(GSN)を形成します。

GGSN リダイレクションについて

Junos OSは、GPRSトンネリングプロトコル(GTP)トラフィックとゲートウェイGPRSサポートノード(GGSN)リダイレクションをサポートしています。GGSN(X)は、後続の GTP-C および GTP-U メッセージに対して異なる GGSN IP アドレス(GGSN Y および GGSN Z)を指定できる、作成 pdp コンテキスト応答を送信できます。その結果、SGSN は、後続の GGSN トンネリング プロトコル、制御(GTP-C)および GGSN トンネリング プロトコル、ユーザー プレーン(GTP-U)メッセージを X ではなく GGSN Y および Z に送信します。

GGSN プーリング シナリオの概要

一般パケット無線サービス(GPRS)トンネリング プロトコル(GTP)は、トンネル作成手順中に異なるゲートウェイ GPRS サポート ノード(GGSN)IP アドレスをサポートします。GPRS サポート ノード(SGSN)ローミングの提供をサポートする 2 つの GGSN プーリング シナリオがあります。

シナリオ 1 の GGSN プーリングについて

図 1 では、GTP トンネルの作成手順中に、パケット データ プロトコル(PDP)コンテキスト要求が SGSN A から GGSN B に送信されます。PDP コンテキスト要求メッセージを送信した後、GGSN D は要求情報を記録し、要求パケットの宛先 IP アドレスとは異なる宛先 IP アドレスを使用して SGSN A に応答メッセージを送信します。

このシナリオでは、中央ポイントによって 2 つの GTP パケット メッセージがサービス処理ユニット 1(SPU1)と SPU2 に送信され、メッセージは SPU1 と SPU2 によって個別に処理されます。セッションは、各 GTP パケットの SPU1 と SPU 2 で作成されます。SPU1は要求パケット情報を記録し、SPU2は応答パケット情報を記録します。

GGSN D から SGSN A に送信された PDP 応答メッセージは、リクエスト情報がないために破棄されます。したがって、GTP トンネルは確立されません。

図 1:GGSN プーリング シナリオ 1 GGSN Pooling Scenario 1
メモ:

SPU2 は、SPU1 からリクエスト情報を取得できません。

リモートSPUへのリクエスト情報のインストール

このシナリオでは、要求情報が不足しているため PDP 応答パケットがドロップされ、GTP トンネルが確立されていません。これは、要求情報を正しいSPUにインストールすることで解決できます。

図 2 では、トンネルを作成すると、応答パケットの GGSN IP アドレスが変更され、新しいセッションがトリガーされ、中央ポイントから別の SPU にメッセージが配信されます。

応答パケットは常にリクエストパケットの送信元アドレスにSPUに送信します。これにより、次の応答パケットのリモートSPUに要求情報をインストールするのに役立ちます。

リクエストパケットの処理中に、リクエスト情報を予測可能なSPU、HASH(req-src-ip)機能にインストールします。予想される SPU 番号(ハッシュ(10.1.1.1)= SPU2)が PDP リクエスト メッセージの送信元 IP アドレスによって計算された後、リクエスト情報は、Juniper Message Passing Interface(JMPI)を介してリモート SPU2 にインストールされます。

図 2:機能:GGSN プーリング シナリオ 1 Functionality : GGSN Pooling Scenario 1

これで、要求情報がローカル SPU1 およびリモート SPU2 にインストールされるため、PDP 応答メッセージが許可されます。

シナリオ 1 の回避策

シナリオ1では、SGSN Aから送信されたPDPコンテキスト要求メッセージがJunos OSのデフォルトアプリケーション junos-gprs-gtp に到達し、PDPコンテキストリクエストメッセージに対してGTPインスペクションが有効になりました。ただし、GGSN D から送信された PDP コンテキスト応答メッセージは、Junos OS のデフォルト アプリケーション junos-gprs-gtpに到達できません。したがって、パケットは GTP モジュールによって検査されません。

回避策として、カスタムポリシーとアプリケーションを設定することで、PDPコンテキストレスポンスメッセージのGTPインスペクションを有効にする必要があります。 GGSN カスタム ポリシー/アプリケーションの設定を参照してください。

シナリオ 2 の GGSN プーリングについて

図 3 では、GTP トンネルの作成手順中に、パケット データ プロトコル(PDP)コンテキスト要求が SGSN A から GGSN B に送信されます。PDP コンテキスト要求メッセージを受信した後、GGSN B は PDP コンテキスト応答メッセージを SGSN A に送信します。PDP コンテキスト応答メッセージを受信すると、SGSN C と GGSN D の間に GTP-C トンネルが作成されます。その後、SGSN C は、リクエスト パケットの IP ヘッダーから異なる送信元と宛先の IP アドレスを使用して、更新 PDP コンテキストリクエスト メッセージを GGSN D に送信します。

シナリオ 2 では、SGSN A は最初の GTP コンテキスト要求を作成し、中央ポイントによって SPU に送信します。SPU1 のリクエスト パケットに対してセッションが作成されます。GGSN B から SGSN A に送信された応答パケットがセッションに正しく到達します。

SGSN Aから送信されたリクエストパケットは、制御IP 10.1.1.2でGTP-Cが確立され、データIP 10.1.1.3でGTP-Uが確立されていることを示しています。同様に、GGSN から送信された応答メッセージは、制御 IP 10.2.2.3 で GTP-C が確立され、データ IP 10.2.2.4 で GTP-U が確立されていることを示しています。

すべてのエンドポイントが確立された後、GTP-CおよびGTP-UトンネルがローカルSPU1で作成されます。ただし、SPU 2 でトンネルが確立されないため、SPU2 から受信した PDP 更新要求メッセージがドロップされます。

図 3:GGSN プーリング シナリオ 2 GGSN Pooling Scenario 2

トンネル情報をリモートSPUにインストールする

シナリオ 2 では、更新要求パケットはトンネル情報が不足しているために破棄されます。これは、要求および応答パケットが処理された後、正しいSPUにトンネル情報をインストールすることで解決できます。応答パケットを受信する SPU は、ローカルまたはリモートの SPU にトンネル情報をインストールします。

図 4 では、トンネルが確立された後、制御メッセージが制御トンネル エンドポイントに送信されます。すべての制御メッセージの宛先 IP アドレスは、制御トンネルの GGSN エンドポイント IP アドレスにする必要があります。これにより、後続の制御メッセージに対して、事前にリモート SPU 番号を計算するのに役立ちます。

トンネル情報を予測可能な SPU にインストールします。制御トンネル GGSN エンドポイント IP によって SPU 番号が計算された後、トンネル情報は JMPI を介してリモート SPU にインストールされます。

図 4:機能:GGSN プーリング シナリオ 2 Functionality : GGSN Pooling Scenario 2

これでトンネル情報がリモート SPU2 にインストールされるため、PDP 更新応答メッセージが許可されます。

例:GGSN カスタム ポリシーとアプリケーションの設定

この例では、ゲートウェイ GPRS サポート ノード(GGSN)カスタム ポリシーおよびアプリケーションを構成して GGSN プーリング シナリオ 1 をサポートする方法を示します。

要件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • SRX5400デバイス

  • A PC

  • Junos OS リリース 12.1X44-D10

構成

GGSN カスタム ポリシーの設定

概要

この例では、GTP プールが発生した場合にトラフィックを動作させる GTP トラフィックのセキュリティ ポリシーを設定する方法を示します。また、この例では、GTP インスペクションの有無にかかわらず、GTP 配信機能が有効になっている場合に、GTP トラフィック フローを正しく行います。ここでは、ミラーリングされた両方向のセキュリティポリシーを設定します。双方向では、同じアドレス オブジェクトと同じアプリケーションを使用します。通常の GTP アプリケーション junos-gprs-gtp に加え、reverse-junos-gprs-gtp という名前のカスタム リバース GTP アプリケーションを作成します。この逆 GTP アプリケーションは、送信元 UDP ポートのみが既知の GTP ポートである場合でも、GTP パケットをセキュリティ ポリシーに一致させます。こうすることで、すべての GTP トラフィックがポリシーに一致し、GTP トラフィックとして正しく処理されます。

CLI クイックコンフィギュレーション

この例を迅速に設定するには、以下のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを 階層レベルの [edit] CLI にコピー アンド ペーストして、設定モードから を入力 commit します。

GTP インスペクションなしで GTP 配信機能が使用される場合、GTP プロファイルを作成しないで、アプリケーション サービス gtp プロファイルをセキュリティ ポリシーに適用しません。

手順

GGSN カスタム ポリシーを設定するには、

  1. 送信元アドレスを設定します。

  2. 宛先アドレスを設定します。

  3. ポリシー・アプリケーションを設定します。

  4. 活動タイプを設定し、GTPプロファイル名を指定します。

    GTP インスペクションなしで GTP 配信機能が使用される場合:

  5. 同じゾーンを再び設定し、セキュリティ ゾーンは信頼と信頼できない逆にします。

結果

設定モードから、 コマンドを入力して設定を show security policies 確認します。出力に意図した設定が表示されない場合は、この例の設定手順を繰り返して修正します。

設定をコミットする前に、リバースGTPアプリケーションを設定する必要があります。

リバース GTP アプリケーションの設定

GTP 配信機能を使用する場合、フロー セッションは一方向として設定されます。一方向に設定するこの操作は、GTP ALG によって実行されます(GTP Inspection を使用していない場合でも)。このため、GTP ALG はすべての GTP トラフィックに適用される必要があります。

事前定義されたアプリケーション junos-gprs-gtp は、GTP ALG で構成されています。ただし、場合によっては、GTP トラフィックがこのアプリケーションと一致しない場合があります。これは、標準の GTP UDP ポートとは異なる送信元ポートが使用された場合のリターン トラフィックの場合になります。この場合、リバース セッション ウィングはランダムな宛先ポートを持ち、標準の GTP ポートを送信元ポートとして持つことができます。この場合、このリバース GTP トラフィックに GTP ALG が適用されるようにするには、すべての GTP セキュリティ ポリシーに以下の「リバース」GTP アプリケーションを追加する必要があります。

CLI クイックコンフィギュレーション

この例を迅速に設定するには、以下のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを 階層レベルの [edit] CLI にコピー アンド ペーストして、設定モードから を入力 commit します。

検証

設定が正しく機能していることを確認します。

設定の検証

目的

GGSN のカスタム ポリシー設定が正しいことを確認します。

アクション

設定をコミットして終了します。動作モードから、 コマンドを show security policies 入力します。

サンプル出力
コマンド名

この出力は、ポリシー設定の概要を示しています。