SRXシリーズファイアウォールでのトラフィック処理の概要
セキュリティデバイス向けJunos OSは、ジュニパーネットワークスのネットワークセキュリティとルーティング機能を統合します。デバイスに出入りするパケットは、パケットベースとフローベースの両方の処理を受けます。
セキュリティ デバイスでのトラフィック処理について
セキュリティデバイス向けJunos OSは、ジュニパーネットワークスの世界クラスのネットワークセキュリティとルーティング機能を統合します。Junos OSは、パケットベースのフィルタリング、サービスクラス(CoS)の分類子、トラフィックシェーピング機能のほか、ポリシー、スクリーン、ネットワークアドレス変換(NAT)、その他のフローベースのサービスを含む豊富で広範なフローベースのセキュリティ機能を備えています。
セキュリティ デバイスに出入りするトラフィックは、パケット フィルター、セキュリティ ポリシー、画面など、ユーザーが設定した機能に従って処理されます。たとえば、ソフトウェアは以下を決定できます。
パケットをデバイスに持ち込むことを許可するかどうか
パケットに適用するファイアウォール画面
パケットが宛先に到達するまでのルート
パケットに適用するCoS(存在する場合)
パケットのIPアドレスの変換にNATを適用するかどうか
パケットにアプリケーション層ゲートウェイ(ALG)が必要かどうか
デバイスに出入りするパケットは、パケットベースとフローベースの両方の処理を受けます。
フローベースのパケット処理は、関連するパケット、またはパケットのストリームを同じ方法で扱います。パケットの処理は、フローと呼ばれるパケットストリームの最初のパケットに確立された特性に依存します。
サービス ゲートウェイの分散処理アーキテクチャでは、すべてのフローベースの処理が SPU で発生し、サンプリングはマルチスレッド対応です。サンプリングされたパケットのパケット順序は維持されます。
パケットベース(ステートレス)のパケット処理は、パケットを個別に処理します。各パケットは、治療のために個別に評価されます。
サービス ゲートウェイの分散処理アーキテクチャでは、トラフィックシェーピングなどの一部のパケットベース処理が NPU で行われます。パケットへの分類子の適用など、一部のパケットベースの処理は SPU で行われます。
このトピックは、以下のセクションで構成されています。
フローベースの処理について
パケットは、パケットベースのフィルターの後にフローベース処理を受け、いくつかの画面が適用されます。1 つのフローに対するすべてのフローベースの処理は、1 つの SPU(サービス処理ユニット)で行われます。SPU は、セッションに設定されたセキュリティ機能やその他のサービスに従って、フローのパケットを処理します。
図 1 は、サービス ゲートウェイでフローベースのトラフィック処理がどのように行われるかの概念図を示しています。
のトラフィック フロー
フローは、同じポリシーの一致基準を定義し、同じ特性を共有する、関連するパケットのストリームです。Junos OS は、同じフローに属するパケットを同じ方法で扱います。
パケットの運命を決定する構成設定。たとえば、適用されるセキュリティ ポリシー、ALG(アプリケーション層ゲートウェイが必要かどうか、パケットの送信元/IP アドレスの変換に NAT が適用されるかどうか)は、フローの最初のパケットに対して評価されます。
パケットのフローが存在するかどうかを判断するために、NPU は、次の一致基準に基づいて、パケットの情報を既存のセッションの情報と照合しようとします。
送信元アドレス
宛先アドレス
送信元ポート
宛先ポート
議定書
特定のゾーンと仮想ルーターの一意のセッショントークン番号
ゾーンとポリシー
フローの最初のパケットに使用されるセキュリティ ポリシーは、同じフローおよび密接に関連するフローで使用するためにフロー テーブルにキャッシュされます。セキュリティ ポリシーはゾーンに関連付けられます。ゾーンは、セキュリティ境界を定義するインターフェイスの集合です。パケットが到着したインターフェイスによって決定されるパケットの受信ゾーンと、転送ルックアップによって決定される発信ゾーンが一緒になって、フローのパケットに使用されるポリシーを決定します。
フローとセッション
ステートフルなフローベースのパケット処理では、セッションの作成が必要です。セッションは、以下の目的でフローの最初のパケットに対して作成されます。
フローのパケットに適用されるセキュリティ対策のほとんどを格納します。
フローの状態に関する情報をキャッシュします。
たとえば、フローのログ記録およびカウント情報は、そのセッションにキャッシュされます。(一部のステートフルファイアウォール画面は、個々のセッションまたはすべてのセッションに関連するしきい値に依存しています。
NAT などの機能のフローに必要なリソースを割り当てます。
ALG やファイアウォール機能などの機能のフレームワークを提供します。
ほとんどのパケット処理は、次のようなフローのコンテキストで行われます。
ポリシー、NAT、ゾーン、およびほとんどの画面の管理。
ALG と認証の管理
パケットベース処理について
パケットは、入力インターフェイスのキューから削除され、出力インターフェイスのキューに追加される前に、パケットベースの処理を受けます。
パケットベースの処理では、ステートレス ファイアウォール フィルター、CoS 機能、一部のスクリーンが個別のパケットに適用されます。
パケットがインターフェイスに到着すると、サニティー チェック、パケットベースのフィルター、一部の CoS 機能、および一部の画面が適用されます。
パケットがデバイスを離れる前に、パケットベースのフィルター、一部のCoS機能、およびインターフェイスに関連する一部の画面がパケットに適用されます。
通常、フィルターと CoS 機能は 1 つ以上のインターフェイスに関連付けられており、どのパケットがシステムを通過できるかに影響を与え、必要に応じてパケットに特別なアクションを適用します。
以下のトピックでは、トランジットトラフィックに設定して適用できるパケットベースの機能の種類について説明します。
ステートレス ファイアウォール フィルター
アクセスコントロールリスト(ACL)とも呼ばれるステートレスファイアウォールフィルターは、アクセスを制御し、トラフィックレートを制限します。送信元から宛先にデバイスを通過するパケットの内容や、ルーティングエンジンから発信されるパケット、または宛てのパケットの内容を静的に評価します。ステートレス ファイアウォール フィルター は、フラグメント化されたパケットを含むすべてのパケットを評価します。
ステートレス ファイアウォール フィルターは、入力インターフェイス、出力インターフェイス、またはその両方に適用できます。フィルターには 1 つ以上の条件が含まれ、各条件は 2 つのコンポーネント(一致条件とアクション)で構成されます。デフォルトでは、ファイアウォールフィルターに一致しないパケットは破棄されます。
ステートレス ファイアウォール フィルターは、トラフィックを特定のプロトコル、IP 送信元または IP 宛先アドレス、データ レートに制限するなど、さまざまな目的に使用できるように計画および設計できます。ステートレス ファイアウォール フィルターは NPU で実行されます。
サービスクラス機能
CoS機能により、トラフィックの分類とシェーピングが可能になります。CoS 機能は NPU で実行されます。
BA(動作集約)分類子 - これらの分類子は、デバイスに入るパケットに対して動作します。デバイスは、動作集約分類子を使用して、異なるタイプのトラフィックを単一の転送クラスに集約し、同じ転送処理を受けます。BA 分類子を使用すると、差別化されたサービス(DiffServ)値に基づいて、パケットの転送クラスと損失の優先度を設定できます。
トラフィックシェーピング:特定のトラフィックフローがサービスを提供する特定のアプリケーションに、遅延、 ジッター、パケット損失の特性の異なるサービスレベルを割り当てることで、トラフィックをシェーピングできます。トラフィックシェーピングは、音声やビデオ伝送などのリアルタイムアプリケーションで特に役立ちます。
画面
サービス拒否(DoS)画面などの一部の画面は、フロー プロセスの外部のパケットに適用されます。これらは、ネットワーク処理ユニット(NPU)で実行されます。
IPv4トラフィックのデフォルト処理動作について
フローベースの処理モードは、ゾーン、スクリーン、ファイアウォールポリシーなどのセキュリティ機能を機能させるために必要です。デフォルトでは、SRXシリーズファイアウォールは、ドロップモードに設定されているSRX300シリーズとSRX550Mデバイスを除くすべてのデバイスでIPv4トラフィックのフローベース転送に対して有効になっています。Junos OS リリース 15.1X49-D70およびJunos OS リリース 17.3R1以降、SRX1500シリーズ、SRX4100、SRX4200、SRX5400、SRX5600、SRX5800、vSRX仮想ファイアウォールデバイスでは、フローモード、パケットモード、ドロップモードでモードを切り替える場合にデバイスを 再起動する必要はありません。 SRX300 シリーズおよび SRX550M デバイスでは、フロー モード、パケット モード、ドロップ モードを切り替えるときにデバイスを再起動 する必要があります 。
SRX300 Series and SRX550M
SRX300 シリーズおよび SRX550M デバイスでは、メモリに制約があるため、デフォルトの処理モードがドロップ モードに設定されています。この場合、処理モードをドロップモードデフォルトからフローベース処理モードまたはパケットベース処理モードに変更した後、つまり、これらのデバイスのモード間で、デバイスを再起動する必要があります。
ドロップモード処理の場合、トラフィックは直接ドロップされ、転送されません。これは、トラフィックは処理されますが、セキュリティ プロセスは適用されないパケット モード処理とは異なります。
Configuring an SRX Series Device as a Border Router
あらゆるタイプのSRXシリーズファイアウォールでフローベース処理またはドロップモードが有効になっている場合、デバイスを境界ルーターとして設定するには、MPLSではモードをパケットベース処理に変更する必要があります。この場合、SRXシリーズファイアウォールをMPLSのパケットモードに設定するには、 set security forwarding-options family mpls mode packet-based ステートメントを使用します。
前述のように、SRX300シリーズおよびSRX550Mデバイスでは、処理モードを変更するたびにデバイスを再起動する必要があります。
SRX210およびSRX320デバイスでのトラフィック処理を理解する
このトピックでは、SRX210 および SRX320 サービス ゲートウェイがデバイスを通過するフローに属するパケットのセッションを確立するプロセスについて説明します。SRX210 および SRX320 デバイスのフロー サービスは、シングルスレッドで非分散型です。この点では他のSRXシリーズファイアウォールとは異なりますが、同じフローモデルに従い、同じCLI(コマンドラインインターフェイス)を実装しています。
セッションの確立と、フローのパケットにサービスが適用されるポイントを含むパケットの「ウォーク」を説明するために、次のセクションで説明する例では、ユニキャスト セッションの単純なケースを使用します。
フロー処理とセッション管理について
このトピックでは、フローを構成するパケットを処理するためのセッションの設定方法について説明します。次のトピックでは、SPUはSRX210またはSRX320ファイアウォールのデータプレーンスレッドを指します。
最初に、データ プレーン スレッドがパケットをフェッチし、基本的なサニティー チェックを実行します。次に、ステートレスフィルターとCoS分類子のパケットを処理し、いくつかの画面を適用します。
ファーストパケット処理について
パケットが既存のフローに属しているかどうかを判断するために、デバイスは、次の 6 つの一致条件に基づいて、パケットの情報を既存のセッションの情報と照合しようとします。
送信元アドレス
宛先アドレス
送信元ポート
宛先ポート
議定書
特定のゾーンと仮想ルーターからの一意のトークン
SPU は、パケットの既存のセッションのセッション テーブルを確認します。既存のセッションが見つからない場合、SPU はフローのセッションを設定します。セッション一致が見つかった場合、セッションはすでに作成されているため、SPU はパケットに対して高速パス処理を実行します。
セッション作成の理解
セッションの設定時に、SPU はパケットに対して次のサービスを実行します。
画面
ルート検索
ポリシー検索
サービス検索
NAT(必要な場合)
セッションが設定されると、フローに属するすべてのパケットに使用されます。フローのパケットは、そのセッションのパラメーターに従って処理されます。パケット処理に必要な残りの手順については、「高速パス処理」の手順 1 に進みます。すべてのパケットは高速パス処理を受けます。
高速パス処理の理解
パケットがセッションに一致する場合、Junos OS は次の手順で説明するように高速パス処理を実行します。フローの最初のパケットにセッションが設定されると、も高速パス処理を受けます。すべてのパケットは高速パス処理を受けます。
SPU は、フローベースのセキュリティ機能をパケットに適用します。
設定した画面が適用されます。
TCP チェックが実行されます。
必要に応じて、NAT、ALG、IPsecなどのフローサービスが適用されます。
SPU は、パケットを転送する準備をして送信します。
ルーティング パケット フィルターが適用されます。
トラフィックシェーピングが適用されます。
トラフィックの優先順位付けが適用されます。
トラフィック スケジューリングが適用されます。
パケットが送信されます。
SRX3000回線およびSRX1400デバイスでのトラフィック処理の理解
SRX1400、SRX3400、SRX3600サービスゲートウェイ向けのJunos OSには、ジュニパーネットワークスの世界クラスのネットワークセキュリティとルーティング機能が統合されています。これらのサービス ゲートウェイ向けの Junos OS には、ポリシー、スクリーン、ネットワーク アドレス変換、サービス クラス分類子などの幅広いセキュリティ サービスや、サービス ゲートウェイの他のデバイスでサポートされている豊富で広範なフローベースのサービスが含まれています。
SRX1400、SRX3400、SRX3600デバイスの分散並列処理アーキテクチャには、セッションを管理し、セキュリティやその他のサービス処理を実行する複数のプロセッサが含まれています。このアーキテクチャは柔軟性を高め、高いスループットと高速なパフォーマンスを実現します。
以下のセクションでは、例としてSRX3400およびSRX3600デバイスを使用した処理アーキテクチャについて説明します。
このトピックでは、次の情報を提供します。
セッションの設定に関連するコンポーネント
以下に、パケットのセッションを設定し、SRX3400 デバイスと SRX3600 デバイスを通過するパケットの処理に関連する主要コンポーネントの概要を示します。
SPU(サービス処理ユニット)—SRX3400およびSRX3600デバイスのメインプロセッサは、サービス処理カード(SPC)に常駐しています。これらはトラフィックフローを確立および管理し、デバイスを通過するパケット上でパケット処理のほとんどを実行します。各SPUは、高速セッション検索のためにハッシュテーブルを維持します。SPU は、セキュリティ サービス、分類子、トラフィック シェーパーのアプリケーションなど、パケットのすべてのフローベースの処理を実行します。同じフローに属するすべてのパケットは、同じ SPU によって処理されます。
SPU は、確立したすべてのセッションと処理するパケットのエントリーを含むセッション テーブルを維持します。SPU は、NPU からパケットを受信すると、そのセッション テーブルをチェックして、パケットがそのSPU に属していることを確認します。
SRX3400 および SRX3600 デバイスでは、1 つの SPU が協調して機能し、通常のセッション管理とフロー処理機能を実行し、セッションの調停とリソースの割り当てを行う中心点として機能します。SPU がこのように動作する場合、それはコンボ モードであると言われます。
中央点—中央点は、ロードバランシング基準に基づいてセッション管理を SPU に割り当てるために使用されます。インテリジェントな方法でセッションを分散し、複数の SPU が同じフローを誤って処理する事態を回避します。中央点は、SPUにセッションを割り当てる際に、ロードバランシング基準に従います。セッションが存在する場合、中央ポイントはそのフローのパケットをホストしている SPU に転送します。また、NPU が失敗した場合には、パケットを正しい SPU にリダイレクトします。
SRX3400 および SRX3600 デバイスでは、1 つの SPU が常にコンボ モードと呼ばれるモードで動作し、中央ポイントの機能とフローおよびセッション管理機能の両方を実装します。コンボ モードでは、SPU と中央ポイントは、同じ負荷分散スレッド(LBT)とパケット順序スレッド(POT)インフラストラクチャを共有します。.
ルーティングエンジン(RE)—ルーティングエンジンはコントロールプレーンを実行し、コントロールプレーンプロセッサー(CPP)を管理します。
ユニキャスト セッションのデータ パスについて
SRX3400およびSRX3600サービスゲートウェイのJunos OSは、分散並列処理、高スループット、高性能システムです。このトピックでは、デバイスを通過するフローに属するパケットのセッションを確立するプロセスについて説明します。
次の例では、セッションの確立と、フローのパケットにサービスが適用されるポイントを含むパケットの「ウォーク」を説明するために、ユニキャスト セッションの単純なケースを使用しています。このパケット「ウォーク」は、Junos OSがパケットに対して実行するパケットベース処理とフローベース処理を統合します。
セッション ルックアップとパケット一致条件
パケットが既存のフローに属しているかどうかを判断するために、デバイスは、次の 6 つの一致条件に基づいて、パケットの情報を既存のセッションの情報と照合しようとします。
送信元アドレス
宛先アドレス
送信元ポート
宛先ポート
議定書
特定のゾーンと仮想ルーターからの一意のトークン
セッション作成について: 最初のパケット処理
このトピックでは、フローを構成するパケットを処理するためのセッションの設定方法について説明します。このプロセスを説明するために、このトピックでは、ソース「a」と宛先「b」の例を使用します。フローのパケットの送信元から宛先への方向は、(a -> b)と呼ばれます。宛先から送信元への方向は、(b->a)と呼ばれます。
パケットがデバイス上のインターフェイスに到着し、IOCがそれを処理します。
IOC はパケットをデキューし、通信相手の NPU に送信します。
NPU は IOC からパケットを受信して処理します。
NPU は、パケットに対して基本的なサニティー チェックを実行し、インターフェイス用に設定されたいくつかの画面をパケットに適用します。
セッションの一致が見つかった場合、セッションは割り当てられた SPU で既に作成されているため、NPU はセッション ID と共に処理するためにパケットを SPU に転送します。
例:パケット(a ->b)はIOC1からNPU1に到達します。NPU1 はサニティー チェックを実行し、DoS 画面をパケットに適用します。NPU1 はセッション テーブルでタプルの一致をチェックしますが、既存のセッションは見つかりません。NPU1 は、SPU に割り当てるためにパケットを SPU1 の中央ポイントに転送します。
中央のポイントは、「保留中」状態のセッションを作成します。
中央ポイントは、デバイス上のすべての SPU に存在するすべてのセッションのエントリーを含むグローバル セッション テーブルを維持します。セッションの作成に参加し、セッションリソースの割り当てを委任および調停します。
このプロセスには、次の部分が含まれます。
中央ポイントは、セッションテーブルとゲートテーブルをチェックして、NPUから受信したパケットにセッションまたはゲートが存在するかどうかを判断します。(NPU は、テーブルにセッションがないことを示しているため、パケットを中央点に転送しました。中央ポイントは、セッションにSPUを割り当てる前に、この情報を確認します)。
どちらのテーブルにもパケットに一致するエントリーがない場合、中央点がセッションの保留中のウィングを作成し、ロードバランシングアルゴリズムに基づいて、セッションに使用するSPUを選択します。
中央ポイントは、フローの最初のパケットをメッセージで選択された SPU に転送し、パケットフローに使用するセッションをローカルに設定するように指示します。
例: 中心点は、セッションの保留中のウィング (a ->b) を作成します。セッションに使用する SPU1 が選択されます。SPU1 に(a->b)パケットをメッセージと共に送信し、SPU1 のセッションを作成します。(SPU1 はコンボ モードで動作する SPU です。そのため、セッションにはセッション管理サービスとフロー処理サービスが使用されます。
SPU がセッションを設定します。
各SPUにも、セッションに関する情報を含むセッションテーブルがあります。SPU は、セッションを設定するために中央ポイントからメッセージを受信すると、セッション テーブルをチェックして、パケットのセッションがまだ存在しないことを確認します。
パケットの既存のセッションがない場合、SPU はローカルでセッションを設定します。
SPU は中央ポイントにメッセージを送信し、セッションをインストールするように指示します。
NAT が有効になっている場合、最初のパケット処理中に、SPU は NAT の IP アドレス リソースを割り当てます。この場合、NAT 割り当て処理が完了するまで、セッションの最初のパケット処理は中断されます。
SPU は、セッションがインストールされるまで、受信する可能性のあるフローの追加パケットをキューに追加します。
例: SPU1 は (a ->b) のセッションを作成し、保留中のセッションをインストールするように指示するメッセージを中央ポイント (同じ SPU に実装) に送り返します。
中央点がセッションをインストールします。
セッションの保留中のウィングの状態をアクティブに設定します。
セッションのリバースウィングをアクティブウィングとして取り付けます。
セッションがインストールされたことを示す ACK(確認)メッセージを SPU に送信します。
例: 中央ポイントは、(a->b) のセッションをインストールするように SPU1 からメッセージを受信します。(a->b)ウィングのセッション状態をアクティブに設定します。セッションにリバースウィング(b->a)を取り付け、アクティブにします。これにより、フローの逆方向からのパケットの配信が可能になります。宛先(B)から送信元(A)に配信されます。
SPU は、イングレスおよびエグレス NPU でセッションを設定します。
NPU は、パケットの転送と配信のためのセッションに関する情報を維持します。セッション情報は、エグレスとイングレスの NPU(同じ場合もあります)に設定されるため、パケットは、リダイレクトの中央ポイントではなく、フローを管理する SPU に直接送信できます。
高速パス処理が行われます。
パケット処理に必要な残りのステップについては、「高速パス処理の理解」のステップ 1 に進みます。
高速パス処理の理解
すべてのパケットは高速パス処理を受けます。ただし、パケットのセッションが存在する場合、パケットは高速パス処理を行い、最初のパケットプロセスをバイパスします。パケットのフローのセッションがすでに存在する場合、パケットは中央点を通過しません。
高速パス処理の仕組みは次のとおりです。 エグレスおよびイングレス インターフェイスの NPU には、パケットのフローを管理する SPU の ID を含むセッション テーブルが含まれています。NPU はこのセッション情報を持っているため、リバース トラフィックを含むフローのすべてのトラフィックは、処理のためにその SPU に直接送信されます。
SRX1400、SRX3400、および SRX3600 デバイスでは、iflset 機能は reth などの集約されたインターフェイスではサポートされていません。
SRX4600デバイスでのトラフィック処理の理解
ジュニパーネットワークスのSRX4600ファイアウォールは、高度なセキュリティと脅威の緩和、従来のステートフルファイアウォールセキュリティを含む、フローベースのセキュリティとルーティングサービスを統合します。Junos OSフローベースのインフラストラクチャは、レイヤー4からレイヤー7のアプリケーションベースサービスの基盤とフレームワークを提供します。SRX4600ファイアウォールは、統合ファイアウォールとして大企業のデータセンターエッジとデータセンターコア、キャンパスエッジに導入するように設計されています。また、LTEセキュリティゲートウェイやGi/SGiファイアウォールとしても展開できます。
このトピックには、次の内容が含まれています。
SRX4600 ファイアウォールとその機能の導入シナリオについて
SRX4600ファイアウォールは、多くの領域に展開して、環境とそのリソースを保護できます。多くの場合、データセンターのエッジとコアを以下の方法で保護するために使用されます。
SRX4600ファイアウォールをデータセンターエッジファイアウォールとして導入
データセンターのエッジにSRX4600ファイアウォールを導入し、ファイアウォールがホストするアプリケーションやサービスに最適な保護を提供できます。すべてのデータセンターには、クライアントがデータセンターのサービスにアクセスできるようにするためのイングレスポイントがありますが、悪意のある攻撃者はこれを利用して、これらのサービスに対して攻撃を仕掛けることができます。データセンターに流入する大量のトラフィックは、イングレスインターネットトラフィックです。このためだけでも、データセンターのエッジに堅牢で多層セキュリティを展開することが不可欠です。SRX4600ファイアウォールは、攻撃を効果的かつ確実にブロックし、特定の種類の攻撃を阻止するようにシステムを構成することができます。SRX4600ファイアウォールは、Juniper Advanced Threat Prevention Cloud(ATP Cloud)を含むジュニパーのSoftware-Defined Secure Network(SDSN)フレームワークをサポートしています。このフレームワークは、脅威を認識して軽減するために迅速に共有できる自動化された実用的なインテリジェンスを中心に構築されています。 図2 は、MX480ルーターおよびEXシリーズスイッチとともにデータセンターのエッジに導入されたSRX4600ファイアウォールを示しています。
図2:データセンターエッジ
にSRX4600ファイアウォールを導入
データセンターのコアにSRX4600ファイアウォールを導入
データセンターのコアにSRX4600ファイアウォールを展開することで、セキュリティを強化し、コンプライアンス要件を確実に満たすことができます。データセンターの処理はますます動的になってきており、明確なネットワーク定義とコンプライアンス要件の実施が必要とされています。コンプライアンスを確保するために、SRX4600ファイアウォールを使用して、ネットワーク全体を個々のサーバーネットワークにセグメント化し、その中でトラフィックを保護します。SRX4600ファイアウォールは高可用性と自動化を提供し、その高パフォーマンスなレイヤー3およびレイヤー4サービスはデータセンターコアのセキュリティ要件を満たします。 図3 は、データセンターのコアに多層ファイアウォールとして導入されたSRX4600ファイアウォールを示しています。
図3:データセンターのコア
にSRX4600ファイアウォールを導入
高度なマルウェア対策機能に加えて、SRX4600ファイアウォールは次の機能をサポートしています。
ステートフルファイアウォール
アプリケーションセキュリティスイート
コンテンツセキュリティ (Sophos AV、Webフィルタリング、スパム対策)
IDP
高可用性(シャーシクラスタ)
デュアルHA制御ポート(10G)
HAポートのMACsecサポート
QSFP28(100G/40G/4x10Gモード)、QSFP+(40G/4x10Gモード)、SFP+(10Gモード)を通したイーサネットインターフェイス
IPSec VPN(AutoVPNおよびグループVPNv2を含む)
QoSとネットワークサービス
J-Webの
マルチキャストのルーティングポリシー
フローベースの処理とセッションの基礎
SRX4600ファイアウォールでのフロー処理を理解するには、フローの基礎を理解することが重要です。
フローは、同じポリシーの一致基準を定義し、同じ特性を共有する、関連するパケットのストリームです。Junos OS は、同じフローに属するパケットを同じ方法で扱います。SRXシリーズサービスゲートウェイのアーキテクチャとパケットフローの処理方法は、密接に結びついています。その結果、アーキテクチャが異なるため、SRXシリーズファイアウォールファミリー全体でフローの実装方法が異なります。
ステートフルなフローベースのパケット処理では、 セッションの作成が必要です。セッションは、ルーティングやその他のトラフィック分類情報に基づいて作成され、情報を格納してフローにリソースを割り当てます。セッションはフローの状態に関する情報をキャッシュし、フローのパケットに適用されるセキュリティ対策のほとんどを保存します。デバイスによってアーキテクチャが異なるため、デバイスによってセッションの管理方法も異なります。
これらの違いにかかわらず、概念的にはフロー プロセスはすべてのサービス ゲートウェイで同じであり、セッションは同じ目的を果たし、同じ機能を備えています。
SRXシリーズファイアウォール全体に実装されたフローとセッション基盤コンポーネント
SRXシリーズファイアウォールは、同じインフラストラクチャコンポーネントを使用してフローをサポートし、セッションを管理しますが、すべてのデバイスがそのすべてを実装しているわけではありません。
フローを理解するには、次のコンポーネントとその使用方法を理解することが不可欠です。
サービス処理ユニット(SPU)
SPU は、パケットフローのセッションを管理します。セキュリティ機能やその他のサービスをパケットに適用します。また、パケットベースのステートレスファイアウォールフィルター、分類子、トラフィックシェーパーをパケットに適用します。
中心点(CP)
中心点は SPU で、リソースを割り当て、SPU 間でセッション管理を分散するためにシステムが使用します。フローの最初のパケットが処理されると、中央ポイントがそのパケットのセッションに使用する SPU を決定します。SRX4600ファイアウォールは、中央点を実装していません。
ネットワーク処理ユニット(NPU)とネットワーク処理セッション
NPU は、I/O カード(IOC)上で動作し、パケットを個別に処理するプロセッサです。フローが作成されると、フローの後続のパケットが NPU のセッションと照合されます。NPUは、TCPシーケンスチェック、TTL(Time-to-live)処理、レイヤー2ヘッダー変換などの追加処理を処理します。NPU は、セッション SPU とハッシュ SPU 間の余分なパケット転送を回避するという点でパフォーマンスを向上させます。SRX4600ファイアウォールはNPUを実装します。
SRX4600ファイアウォールフローアーキテクチャが改善され、SRX4600デバイスの高度なマルチコアXeon™プロセッサーの使用が最適化されました。SRX4600ファイアウォールは、専用のセッションスレッドの使用を実装して、フロー内の誤順序パケットの管理などの問題を回避します。ネットワーク処理セッションを利用して、パケットが適切な専用スレッドに転送されるようにします。パケットは、ハッシュベースのセッション分散モデルに従って、異なるスレッドに分散されます。
SRX5000回線デバイスでのトラフィック処理の理解
SRX5000デバイスにJunos OSのは、分散された並列処理、高スループット、高性能なシステムです。SRX5000シリーズサービスゲートウェイの分散並列処理アーキテクチャには、セッションを管理し、セキュリティやその他のサービス処理を実行する複数のプロセッサが含まれています。このアーキテクチャは柔軟性を高め、高いスループットと高速なパフォーマンスを実現します。
SRX1400、SRX3400、SRX3600、SRX5400、SRX5600、およびSRX5800デバイスでは、ネゴシエーション中にIKEパケットの送信元IPアドレスを変更するNATデバイスの背後にIKEピアがある場合、NATトラバーサルを含むIKEネゴシエーションは機能しません。たとえば、NATデバイスがDIPで設定されている場合、IKEプロトコルによってUDPポートが500から4500に切り替わるため、送信元IPが変更されます。
SRX5000シリーズデバイスのI/Oカード(IOC)とサービス処理カード(SPC)には、デバイスを通過するパケットを処理する処理ユニットが含まれています。IOC には 1 つ以上のネットワーク処理ユニット(NPU)があり、SPC には 1 つ以上のサービス処理ユニット(SPU)があります。
これらの処理ユニットには、異なる責任があります。パケットのすべてのフローベース サービスは、1 つの SPU で実行されます。これらのNPUの責任は、そこで実行される他の種類のサービスに関して明確に線引きされていません。.)
例えば：
NPU はパケットを個別に処理します。サニティー チェックを実行し、サービス拒否(DoS)画面など、インターフェイスに設定された一部の画面をパケットに適用します。
SPU は、パケット パケットフローのセッションを管理し、セキュリティ機能やその他のサービスをパケットに適用します。また、パケットベースのステートレスファイアウォールフィルター、分類子、トラフィックシェーパーをパケットに適用します。
NPU は、ハッシュ アルゴリズムを使用して SPU にパケットを転送します。ただし、ALG などの一部のアプリケーションでは、パケットを処理する必要がある SPU を決定するために、システムがアプリケーションの中央点にクエリーを実行する必要があります。
これらの中心点を含むシステムの個別の連携部分には、パケットのストリームに対してセッションが存在するかどうかを識別する情報と、パケットが既存のセッションに属しているかどうかを判断するためにパケットを照合する情報が格納されます。
このアーキテクチャにより、デバイスはすべてのセッションの処理を複数の SPU に分散できます。また、NPUは、パケットにセッションが存在するかどうかを判断し、パケットをチェックし、パケットに画面を適用することもできます。パケットがどのように処理されるかは、そのパケットがフローの最初のパケットであるかどうかによって異なります。
以下のセクションでは、例としてSRX5400、SRX5600、およびSRX5800デバイスを使用した処理アーキテクチャについて説明します。
- ファーストパケット処理について
- 高速パス処理の理解
- ユニキャスト セッションのデータ パスについて
- サービス処理ユニットについて
- スケジューラの特性の理解
- ネットワーク・プロセッサのバンドリングについて
ファーストパケット処理について
図 4 は、フローの最初のパケットがデバイスに入るまでのパスを示しています。NPU は、パケットのセッションが存在しないと判断し、パケットを分散中央ポイントに送信して、分散中央ポイント セッションを設定します。その後、分散された中央ポイントは、アプリケーションの中央ポイントにメッセージを送信して、SPU を選択してパケットのセッションを設定し、パケットを処理します。分散型中央点は、そのSPUにパケットを送信します。SPU はパケットを処理し、デバイスから送信するために NPU に送信します。(この高レベルの説明では、パケットへの機能の適用については説明しません)。
フローの最初のパケットがシステムを通過し、セッションが確立された後、高速パス処理が行われます。
フロー内の後続のパケットも高速パス処理を受けます。この場合、各パケットがセッションに入り、NPU がセッション テーブルで一致するものを見つけた後、NPU はセッションを管理する SPU にパケットを転送します。
図 5 は、高速パス処理を示しています。これは、関連するパケットに対してフローがすでに確立されている場合にパケットがたどるパスです。(これは、パケットが開始したフローのセッションが設定された後にフローの最初のパケットがたどるパスでもあります。)パケットがデバイスに入ると、NPU はセッション テーブルでパケットに一致するものを見つけ、パケットのセッションを管理する SPU にパケットを転送します。パケットは中央点との相互作用をバイパスすることに注意してください。
高速パス処理の理解
次のセクションでは、セッションの作成方法と、パケットがデバイスを通過するときに受けるプロセスについて説明します。
ここでは、パケットのセッションを設定し、パケットがSRX5400、SRX5600、SRX5800デバイスを通過する際に、離散的に、およびフローの一部としてパケットを処理することに関連する主要コンポーネントの概要を説明します。
ネットワーク処理ユニット(NPU)—NPUはIOCに存在します。パケットのサニティチェックと一部の画面の適用を処理します。NPU は、受信パケットまたはリバース トラフィックのどちらにセッションが存在するかを判断するために使用するセッション テーブルを維持します。
NPU セッション テーブルには、以前にインターフェイス経由でデバイスに入り、この NPU によって処理されたパケットのセッションが SPU で確立された場合、セッションのエントリーが含まれます。SPU は、セッションの作成時に、NPU テーブルにセッションをインストールします。
NPU は、パケット情報をセッション テーブルと照合して、パケットのセッションが存在するかどうかを判断します。パケットが既存のセッションと一致する場合、NPU はパケットとそのメタデータを SPU に送信します。セッションがない場合、NPU はハッシュ アルゴリズムを使用して計算された 1 つの SPU にパケットを送信します。
SPU(サービス処理ユニット)—SRX5400、SRX5600、およびSRX5800デバイスのメインプロセッサは、SPCに常駐しています。SPUは、トラフィックフローを確立および管理し、デバイスを通過するパケット上でほとんどのパケット処理を実行します。各SPUは、高速セッション検索のためにハッシュテーブルを維持します。SPU は、ステートレス ファイアウォール フィルター、分類子、トラフィック シェーパーをトラフィックに適用します。SPU は、パケットのすべてのフローベース処理と、ほとんどのパケットベース処理を実行します。各マルチコア SPU は、同一または異なる SPC 上の SPU 間の相互作用を最小限に抑えながら、個別にパケットを処理します。同じフローに属するすべてのパケットは、同じ SPU によって処理されます。
SPU は、確立したすべてのセッションと処理するパケットのエントリーを含むセッション テーブルを維持します。SPU は、NPU からパケットを受信すると、そのセッション テーブルをチェックして、パケットがそのSPU に属していることを確認します。また、分散中央点からパケットを受信すると、セッションテーブルをチェックし、そのパケットのセッションを確立するメッセージを送信して、パケットの既存のセッションがないことを確認します。
中心点—中心点アーキテクチャは、アプリケーションの中心点と分散型中心点の 2 つのモジュールに分かれています。アプリケーションの中央点はグローバルリソース管理とロードバランシングを担当し、分散中央点はトラフィックの識別(グローバルセッションマッチング)を担当します。アプリケーションの中央ポイント機能は専用の中央ポイント SPU で実行され、分散された中央ポイント機能は残りの SPU に分散されます。これで、中央ポイント セッションは専用の中央ポイント SPU ではなく、他のフロー SPU の分散中央ポイントになりました。
ルーティングエンジン-ルーティングエンジンはコントロールプレーンを実行します。
ユニキャスト セッションのデータ パスについて
このセクションでは、デバイスを通過するフローに属するパケットのセッションを確立するプロセスについて説明します。
この例では、セッションの確立と、フロー内のパケットにサービスが適用されるポイントを含むパケットの「ウォーク」を説明するために、ユニキャスト セッションの単純なケースを使用します。
このパケット「ウォーク」は、Junos OSがパケットに対して実行するパケットベース処理とフローベース処理を統合します。
セッション ルックアップとパケット一致条件
パケットが既存のフローに属しているかどうかを判断するために、デバイスは、次の 6 つの一致条件に基づいて、パケットの情報を既存のセッションの情報と照合しようとします。
送信元アドレス
宛先アドレス
送信元ポート
宛先ポート
議定書
特定のゾーンと仮想ルーターからの一意のトークン
セッション作成について:ファーストパケット処理
このセクションでは、フローを構成するパケットを処理するためのセッションの設定方法について説明します。このプロセスを説明するために、このセクションでは、ソース「a」と宛先「b」の例を使用します。フローのパケットの送信元から宛先への方向は、(a ->b)と呼ばれます。宛先から送信元への方向は、(b->a)と呼ばれます。
ステップ1。パケットがデバイス上のインターフェイスに到着し、NPUがそれを処理します。
このセクションでは、パケットがSRXシリーズファイアウォールイングレスIOCに到着したときに、パケットがどのように処理されるかについて説明します。
パケットはデバイスの IOC に到着し、IOC の NPU によって処理されます。
NPU は、パケットに対して基本的なサニティー チェックを実行し、インターフェイス用に設定されたいくつかの画面をパケットに適用します。
NPU は、パケットの既存のセッションのセッション テーブルをチェックします。(パケットのタプルを、セッションテーブル内の既存のセッションのパケットのタプルと照合します)。
既存のセッションが見つからない場合、NPU はパケットをハッシュ SPU に転送します。
セッションの一致が見つかった場合、セッションは割り当てられた SPU で既に作成されているため、NPU はセッション ID と共に処理するためにパケットを SPU に転送します。
Example: パケット(a ->b)が NPU1 に到達します。NPU1 はサニティー チェックを実行し、DoS 画面をパケットに適用します。NPU1 はセッションテーブルでタプルの一致をチェックしますが、既存のセッションは見つかりません。NPU1 はパケットを SPU に転送します。
ステップ2。分散された中央点は、「保留中」状態のセッションを作成します。
NPU がパケットを受信すると、NPU はハッシュ アルゴリズムに基づいて、分散された中央点にパケットを送信します。次に、分散中心点は、分散中心点セッション テーブルを検索し、必要に応じてエントリを作成します。
このプロセスには、次の部分が含まれます。
分散セントラル ポイントは、セッション テーブルをチェックして、NPU から受信したパケットのセッションが存在するかどうかを判断します。(NPUは、パケットの既存のセッションを見つけることができないため、分散された中央点にパケットを転送します)
分散中心点セッション テーブル内のパケットに一致するエントリがない場合、分散中心点はセッションの保留中のウィングを作成します。次に、分散された中央ポイントは、アプリケーションの中央ポイントにクエリ メッセージを送信して、セッションに使用する SPU を選択します。
クエリメッセージを受信すると、アプリケーションのセントラルポイントがゲートテーブルをチェックして、パケットのゲートが存在するかどうかを判断します。ゲートが一致した場合、または他のセッション分散アルゴリズムがトリガーされた場合、アプリケーションの中央ポイントはパケットを処理する別のSPUを選択します。それ以外の場合は、SPU(つまり、分散された中央点SPU)が選択されます。最後に、アプリケーションの中央点は、分散された中央点にクエリ応答を送信します。
クエリ応答を受信すると、分散中央ポイントは、フロー内の最初のパケットをメッセージ内の選択された SPU に転送し、パケットフローに使用するセッションをローカルに設定するように SPU に指示します。たとえば、分散された中心点は、セッションの保留中のウィング(a ->b)を作成します。アプリケーションの中央点は、使用する SPU1 を選択します。分散中央ポイントは、SPU1 にメッセージと共に (a->b) パケットを送信して、分散中央ポイントのセッションを作成します。
Example: 分散中心点は、セッションの保留中のウィング(a ->b)を作成します。使用する SPU1 が選択されます。SPU1 に(a->b)パケットをメッセージと共に送信し、SPU1 のセッションを作成します。
ステップ3。SPU がセッションを設定します。
各SPUにも、セッションに関する情報を含むセッションテーブルがあります。SPU は、分散された中央点からセッションを設定するメッセージを受信すると、セッション テーブルをチェックして、パケットのセッションがまだ存在しないことを確認します。
パケットの既存のセッションがない場合、SPU はローカルでセッションを設定します。
SPU は、分散された中央ポイントにメッセージを送信し、セッションをインストールするように指示します。
手記：NAT が有効になっている場合、最初のパケット処理中に、SPU は NAT の IP アドレス リソースを割り当てます。この場合、NAT 割り当て処理が完了するまで、セッションの最初のパケット処理は中断されます。
SPU は、セッションがインストールされるまで、受信する可能性のあるフローの追加パケットをキューに追加します。
Example: SPU1 は (a ->b) のセッションを作成し、分散された中央ポイントにメッセージを送り返して、保留中のセッションをインストールするように指示します。
ステップ4.分散中央点がセッションをインストールします。
分散された中央ポイントは、SPU からインストール メッセージを受信します。
分散された中心点は、セッションの保留中のウィングの状態をアクティブに設定します。
分散中心点は、セッションのリバースウィングをアクティブウィングとして設置します。
手記：NATなどの一部のケースでは、後方翼は、初期翼の分散中心点とは異なる分散中心点に設置される場合があります。
セッションがインストールされたことを示す確認応答(ACK)メッセージをSPUに送信します。
Example: 分散中央点は、SPU1 から(a->b)ウィングのセッションをインストールするためのメッセージを受信します。これは、(a->b)ウィングのセッション状態をアクティブに設定します。セッションにリバースウィング(b->a)を取り付け、アクティブにします。これにより、フローの逆方向からのパケットの配信が可能になります。宛先(B)から送信元(A)に配信されます。
ステップ5.SPU は、イングレスとエグレスの NPU でセッションを設定します。
NPU は、パケットの転送と配信のためのセッションに関する情報を維持します。セッション情報は、エグレスとイングレスの NPU(同じ場合もあります)で設定されるため、パケットは、リダイレクトのための分散された中央ポイントではなく、フローを管理する SPU に直接送信できます。
ステップ6.高速パス処理が行われます。
パケット処理に必要な残りのステップについては、 高速パス処理のステップ 1 に進みます。
図 6 は、フロー内の最初のパケットがデバイスに到達した後に通過するプロセスの最初の部分を示しています。この時点で、パケットとそのフローに属する残りのパケットを処理するようにセッションが設定されます。その後、それとフロー内の残りのパケットは高速パス処理を受けます。
高速パス処理の理解
すべてのパケットは高速パス処理を受けます。ただし、パケットのセッションが存在する場合、パケットは高速パス処理を行い、最初のパケットプロセスをバイパスします。パケットのフローのセッションがすでに存在する場合、パケットは中央点を通過しません。
高速パス処理の仕組みは次のとおりです。 エグレスおよびイングレス インターフェイスの NPU には、パケットのフローを管理する SPU の ID を含むセッション テーブルが含まれています。NPU はこのセッション情報を持っているため、リバース トラフィックを含むフローのすべてのトラフィックは、処理のためにその SPU に直接送信されます。
高速パス プロセスを説明するために、このセクションでは、送信元「a」と宛先「b」の例を使用します。フローのパケットの送信元から宛先への方向は、(a->b)と呼ばれます。宛先から送信元への方向は、(b->a)と呼ばれます。
ステップ1。パケットがデバイスに到着し、NPU がそれを処理します。
このセクションでは、パケットがサービス ゲートウェイの IOC に到着したときにパケットがどのように処理されるかについて説明します。
パケットはデバイスの IOC に到着し、カード上の NPU によって処理されます。
NPU はサニティー チェックを実行し、サービス拒否(DoS)画面などの一部の画面をパケットに適用します。
NPU は、パケットが一致するセッション テーブル内の既存のセッションのエントリーを識別します。
NPU は、セッション ID とパケット タプル情報を含むセッション テーブルからのメタデータと共にパケットを SPU に転送します。SPU はフローのセッションを管理し、ステートレス ファイアウォール フィルターと CoS 機能をパケットに適用し、パケットのフロー処理とセキュリティやその他の機能の適用を処理します。
Example: パケット(a ->b)が NPU1 に到達します。NPU1 はパケットに対してサニティー チェックを実行し、DoS 画面を適用し、タプルの一致についてセッション テーブルをチェックします。一致するものを検出し、SPU1 のパケットに対してセッションが存在することが分かります。NPU1 は、処理のためにパケットを SPU1 に転送します。
ステップ2。セッションの SPU がパケットを処理します。
パケットの処理のほとんどは、セッションが割り当てられている SPU で行われます。パケットは、ステートレス ファイアウォール フィルター、トラフィック シェーパー、分類子(該当する場合)などのパケットベース機能のために処理されます。設定されたフローベースのセキュリティと、ファイアウォール機能、NAT、ALGなどの関連サービスがパケットに適用されます。(セッションのセキュリティ サービスがどのように決定されるかについての詳細。
パケットを処理する前に、SPU はセッション テーブルをチェックして、パケットがセッションの 1 つに属していることを確認します。
SPU は、該当する機能とサービスのパケットを処理します。
Example: SPU1 は、NPU1 からパケット(a->b)を受信します。SPU1 はセッション テーブルをチェックして、パケットがそのセッションの 1 つに属していることを確認します。次に、その入力インターフェイスに適用される入力フィルターとCoS機能に従って、パケット(->b)を処理します。SPU は、ゾーンとポリシーに基づいて、パケットのフロー用に構成されたセキュリティ機能とサービスを適用します。設定されている場合は、出力フィルター、トラフィックシェーパー、および追加の画面をパケットに適用します。
ステップ3。SPU はパケットを NPU に転送します。
SPU はパケットを NPU に転送します。
NPU は、インターフェイスに関連付けられている該当するスクリーンをパケットに適用します。
Example: SPU1 はパケット(a ->b)を NPU2 に転送し、NPU2 は DoS 画面を適用します。
ステップ4.インターフェイスは、デバイスからのパケットを送信します。
Example: インターフェイスは、デバイスからのパケット(a->b)を送信します。
ステップ5.リバーストラフィックパケットがエグレスインターフェイスに到着し、NPUがそれを処理します。
このステップでは、ステップ 1 とはまったく逆のミラーリングを行います。詳細については、このセクションのステップ 1 を参照してください。
Example: パケット(b->a)がNPU2に到達します。NPU2 は、タプルが一致するかどうかセッションテーブルをチェックします。一致するものを検出し、SPU1 のパケットに対してセッションが存在することが分かります。NPU2 は、処理のためにパケットを SPU1 に転送します。
ステップ6.セッションの SPU は、リバース トラフィック パケットを処理します。
このステップはステップ 2 と同じですが、リバース トラフィックに適用される点が異なります。詳細については、このセクションのステップ 2 を参照してください。
Example: SPU1 は NPU2 からパケット(b->a)を受信します。パケットはセッションテーブルをチェックして、パケットが NPU2 によって識別されるセッションに属していることを確認します。次に、NPU1 のインターフェイスに設定されたパケットベースの機能をパケットに適用します。パケット(B->a)は、ゾーンとポリシーに基づいて、そのフローに設定されたセキュリティ機能やその他のサービスに従って処理されます。
ステップ7.SPU は、リバース トラフィック パケットを NPU に転送します。
このステップはステップ 3 と同じですが、リバース トラフィックに適用される点が異なります。詳細については、このセクションのステップ 3 を参照してください。
Example: SPU1 はパケット(b->a)を NPU1 に転送します。NPU1 は、インターフェイスに設定された画面をすべて処理します。
8.インターフェイスは、デバイスからパケットを送信します。
このステップはステップ 4 と同じですが、リバース トラフィックに適用される点が異なります。詳細については、このセクションのステップ 4 を参照してください。
例:インターフェイスは、デバイスからパケット(b->a)を送信します。
図 7 は、パケットがデバイスに到達し、そのパケットが属するフローにセッションが存在する場合のプロセスを示しています。
のパケットウォーク
サービス処理ユニットについて
特定の物理インターフェイスについて、SPU は、物理インターフェイスに関連付けられたネットワーク プロセッサ バンドル内のすべてのネットワーク プロセッサからイングレス パケットを受信します。SPU は、物理インターフェイスからネットワーク プロセッサ バンドル情報を抽出し、同じ 5 タプル ハッシュ アルゴリズムを使用してフローをネットワーク プロセッサ インデックスにマッピングします。ネットワーク プロセッサを特定するために、SPU はネットワーク プロセッサ バンドル内のネットワーク プロセッサ インデックスを検索します。SPU は、外向きトラフィックの物理インターフェイスのローカル物理インターフェイス モジュール(PIM)にエグレス パケットを送信します。
ネットワーク プロセッサーと SPU は、同じ 5 タプル ハッシュ アルゴリズムを使用して、パケットのハッシュ値を取得します。
スケジューラの特性の理解
SRX5400、SRX5600、および SRX5800 デバイスの場合、IOC は次の階層スケジューラ特性をサポートします。
IFL – ネットワークプロセッサーバンドルの設定は、物理インターフェイスデータ構造に保存されます。たとえば、SRX5400、SRX5600、SRX5800 デバイスには最大 48 個の PIM があります。物理インターフェイスでは、48 ビット ビットマスクを使用して PIM を示すか、この物理インターフェイスからのネットワーク プロセッサ トラフィックが物理インターフェイスのプライマリ ネットワーク プロセッサに加えて分散されます。
SRX5000シリーズデバイスでは、 iflset機能はrethなどの集約型インターフェイスではサポートされていません。
IFD – ネットワークプロセッサバンドルの物理インターフェイスに関連付けられた 論理インターフェイス は、ネットワークプロセッサバンドル内に PIM を持つすべての IOC に渡されます。
ネットワーク・プロセッサのバンドリングについて
ネットワーク プロセッサ バンドリング機能は、SRX5000シリーズ デバイスで使用できます。この機能により、パケット処理のために、1つのインターフェイスから複数のネットワークプロセッサにデータトラフィックを分配することができます。プライマリネットワークプロセッサは、イングレストラフィックを受信し、そのパケットを他の複数のセカンダリネットワークプロセッサに分配するインターフェイスに割り当てられます。単一のネットワークプロセッサが、複数のインターフェイスに対してプライマリネットワークプロセッサまたはセカンダリネットワークプロセッサとして動作できます。1 つのネットワーク・プロセッサーは、1 つのネットワーク・プロセッサー・バンドルにのみ参加できます。
ネットワーク・プロセッサー・バンドリングの制限
ネットワーク・プロセッサーのバンドル機能には、以下の制限があります。
ネットワーク・プロセッサー・バンドリングでは、バンドルごとに合計16のPIMと、8つの異なるネットワーク・プロセッサー・バンドル・システムを使用できます。
バンドルに設定変更を適用するには、デバイスを再起動する必要があります。
ネットワークプロセッサのバンドルは、アーキテクチャ全体においてrethインターフェイスより下位にあります。ネットワーク・プロセッサー・バンドルから一方または両方のインターフェースを選択して、reth インターフェースを形成することができます。
IOC がネットワーク プロセッサ バンドルから削除されると、その IOC の PIM に転送されたパケットは失われます。
ネットワーク・プロセッサー・バンドルが有効な場合、ICMP、UDP、およびTCP同期フラッディングしきい値はインターフェイスに適用されなくなります。パケットは、処理のために複数のネットワークプロセッサに分配されます。これらのしきい値は、ネットワーク・プロセッサー・バンドル内の各ネットワーク・プロセッサーに適用されます。
ネットワークプロセッサのバンドルは、レイヤー2モードではサポートされていません。
ネットワーク プロセッサのメモリの制約により、PIM ごとにサポートされるネットワーク プロセッサ バンドル ポートの数は制限されています。ネットワーク・プロセッサー・バンドル内では、各ポートにグローバル・ポート・インデックスが必要です。グローバルポートインデックスは、次の式を使用して計算されます。
Global_port_index = (global_pic * 16) + port_offset
シャーシ クラスタ実装のリンク アグリゲーション グループ(LAG)と冗長イーサネット インターフェイス LAG は、ネットワーク プロセッサのバンドルと共存できます。ただし、LAGも冗長イーサネットインターフェイスLAGも、ネットワークプロセッサバンドルと重複したり、物理リンクを共有したりすることはできません。
セッションキャッシュの理解
概要
SRX5400、SRX5600、SRX5800 デバイス上の SRX5K-MPC(IOC2)、SRX5K-MPC3-100G10G(IOC3)、SRX5K-MPC3-40G10G(IOC3)は、セッション キャッシュとセッション キャッシュの選択的インストールをサポートしています。
セッション キャッシュは、ネットワーク プロセッサ(NP)と IOC 上の SPU 間の会話をキャッシュするために使用されます。カンバセーションは、セッション、GTP-Uトンネルトラフィック、IPSec VPNトンネルトラフィックなどです。カンバセーションには 2 つのセッション キャッシュ エントリーがあり、1 つは受信トラフィック用、もう 1 つはリバース トラフィック用です。トラフィックのイングレスポートとエグレスポートの場所に応じて、2つのエントリーが同じネットワークプロセッサーに存在する場合もあれば、異なるネットワークプロセッサーに存在する場合もあります。IOC は、IPv6 セッションのセッション キャッシュをサポートします。
セッションキャッシュエントリは、 セッションウィングとも呼ばれます。
IOC のセッション キャッシュは、Express Path(以前は サービス オフロードと呼ばれていました)機能を活用し、高遅延や IPsec パフォーマンスの低下などの問題を防ぐのに役立ちます。
セッション・キャッシュ・エントリーは、以下を記録します。
変換のトラフィックを転送する SPU
変換のトラフィックを Express Path モードで転送するエグレス ポート
エグレストラフィックに対して行う処理(例えば、Express PathモードでのNAT変換)
Junos OS リリース 15.1X49-D10 および Junos OS リリース 17.3R1 以降、IOC 内のセッションのセッション キャッシュは、特定のパフォーマンスの問題の解決に役立ちます。SPU は、後続のトラフィックを特定のアンカー SPU に転送するように IOC セッション キャッシュに指示できるようになりました。
Junos OS リリース 15.1X49-D10 以降、SRX5K-MPC(IOC2)および IOC3 は、改善されたフロー モジュールとセッション キャッシュを通じて、VPN セッション アフィニティをサポートします。Junos OS リリース 12.3X48-D30 以降、IOC2 では、セッション キャッシュを介した VPN セッション アフィニティがサポートされています。
その他のトラフィックは、5 タプルのキー情報に基づいて SPU にハッシュされました。VPN トラフィックにはアンカー SPU の概念が採用されていましたが、これは必ずしもフロー SPU の機能と一致していませんでした。ネットワーク プロセッサは、5 タプル ハッシュに基づいてフロー SPU にのみパケットを転送できます。その後、フロー SPU はパケットを固定された SPU に転送しました。これにより、VPNトラフィックに余分なホップが発生し、スイッチファブリックの帯域幅を浪費し、VPNスループットが約半分に減少しました。このパフォーマンスの低下は、アンカーされた SPU で処理した後も、トラフィックがフロー SPU に戻る必要があったために発生しました。
セッション キャッシュ テーブルが IOC に拡張され、NP セッションがサポートされるようになりました。Express Path トラフィックと NP トラフィックは、IOC 上で同じセッション キャッシュ テーブルを共有します。Express Path のトラフィックは SPU からのサービスを必要としないため、IOC 自体によってローカルまたは別の IOC に転送されます。NP トラフィックは、さらに処理するためにセッション キャッシュで指定された SPU に転送されます。すべてのセッション キャッシュ エントリは、Express Path セッション トラフィックと NP トラフィックの両方で共有されます。
IOCでセッションキャッシュを有効にするには、 set chassis fpc <fpc-slot> np-cache コマンドを実行する必要があります。
IOC2 と IOC3 は、遅延セッション削除メカニズムを利用します。同じセッション(同じ 5 つのタプルを持つセッション)が削除され、すぐに再インストールされた場合は、IOC にキャッシュされません。
選択的セッションキャッシュインストール
高遅延を回避し、IPSec のパフォーマンスを向上させ、貴重なリソースをより有効に活用するために、フロー モジュールと IOC の両方に特定の優先順位メカニズムが適用されます。
IOCは、セッションキャッシュ使用しきい値レベルを維持および監視します。また、IOC はセッション キャッシュの使用状況を SPU に伝えるため、特定のセッション キャッシュ使用量のしきい値に達すると、SPU は選択した優先度の高いトラフィック セッションのセッション キャッシュのインストール要求のみを送信します。
IDP、ALGなどのアプリケーションは、パケットを順番に処理する必要があります。1 つの SPU には、1 つのセッションに属するパケットを処理する複数のフロー スレッドがあり、ロードバランシング スレッド(LBT)、パケット順序付けスレッド(POT)パケット順序により、トラフィックがファイアウォールを順番に通過できますが、同じセッションに属するパケットを順番に処理するアプリケーションは保証できません。フロー シリアル化では、同じセッションに一度に 1 つの SPU フロー スレッド処理パケットのみが属するという方法が提供されるため、アプリケーションはパケットを順番に受信、処理、送信できます。他のフロー スレッドは、他のセッションのフローのシリアル化処理を同時に実行できます。
次の 4 つの優先度レベルで、IOC にセッション キャッシュをインストールできるトラフィックの種類が決定されます。
Priority 1 (P1)— IPSec および Express Path 認定トラフィック
Priority 2 (P2)— フラグメンテーションの順序付け
Priority 3 (P3)— NAT/SZ(セッションシリアル化)トラフィック
Priority 4(P3)— その他すべてのタイプのトラフィック
IOC は、セッション キャッシュ使用のしきい値レベルを維持および監視し、現在のリアルタイム セッション キャッシュ使用状況を SPU に更新します。SPU は、特定の優先度の高いトラフィック セッションのセッション キャッシュをインストールするよう IOC に要求します。優先度の高いトラフィックセッションでのセッションキャッシュの使用量は、以下の表で定義されています。
トラフィック タイプ |
0%<使用率<25% |
利用率<25%<50% |
利用率<50%<75% |
利用率75%<100%< |
|---|---|---|---|---|
IPsec および Express Path トラフィック |
はい |
はい |
はい |
はい |
フラグメント化 トラフィックの順序付け |
はい |
はい |
はい |
いいえ |
NAT/SZトラフィック |
はい |
はい |
いいえ |
いいえ |
その他のトラフィック |
はい |
いいえ |
いいえ |
いいえ |
IOC でセッション エントリを保存するために、フロー モジュールは IOC にセッションを選択的にインストールします。セッション インストールの選択を容易にするために、IOC は対応するしきい値を維持して、フロー モジュールに(IOC のセッション キャッシュ テーブルのフル状態に関する)指標を提供します。メタヘッダーに 2 ビットが追加され、現在のキャッシュテーブルの使用状況を示します。SPU に向かうすべてのパケットは、これら 2 つのステータス ビットを伝送し、IOC のキャッシュ テーブルの使用率をフロー モジュールに通知します。
セッションキャッシュを使用したIPSec VPNセッションアフィニティの強化
SRXシリーズファイアウォールは完全に分散されたシステムであり、IPsec トンネルは特定のSPUに割り当てられ、固定されます。IPsec トンネルに属するすべてのトラフィックは、トンネルアンカー SPU で暗号化および復号化されます。IPsec のパフォーマンスを向上させるために、IOC はフロー モジュールを改善して、トンネルアンカー SPU で IPsec トンネルベースのトラフィックのセッション(暗号化前と復号化後)を作成し、IOC がパケットを同じ SPU に直接リダイレクトできるようにセッションのセッション キャッシュをインストールして、パケット転送のオーバーヘッドを最小限に抑えます。Express Path トラフィックと NP トラフィックは、IOC 上で同じセッション キャッシュ テーブルを共有します。
IOCでセッションキャッシュを有効にし、セキュリティポリシーを設定して、選択したFPC(フレキシブルPICコンセントレータ)でセッションがExpress Path( 以前はサービスオフローディングと呼ばれていました)モードかどうかを判断する必要があります。
IPSec VPN アフィニティーの使用を有効にするには、 set security flow load-distribution session-affinity ipsec コマンドを使用します。
IPSec VPN アフィニティーを有効にするには、 set chassis fpc <fpc-slot> np-cache コマンドを使用して IOC のセッションキャッシュも有効にする必要があります。
NP セッション キャッシュを使用したフラグメンテーション パケット順序
セッションは、通常のパケットとフラグメント化されたパケットの両方で構成されている場合があります。ハッシュベースの配信では、5 タプルと 3 タプルの鍵を使用して、通常のパケットとフラグメント化されたパケットをそれぞれ異なる SPU に分散できます。SRXシリーズファイアウォールでは、セッションのすべてのパケットが処理SPUに転送されます。転送と処理の遅延により、処理 SPU がセッションのパケットの順序を保証しない場合があります。
IOC のセッション キャッシュは、フラグメント化されたパケットを含むセッションのパケットの順序を確保します。セッション キャッシュ エントリはセッションの通常のパケットに割り当てられ、フラグメント化されたパケットを見つけるのに 3 タプル キーが使用されます。セッションの最初のフラグメント化されたパケットを受信すると、フロー モジュールは、IOC が SPU のフラグメント化されたパケットを記憶するようにセッション キャッシュ エントリを更新できるようにします。その後、IOC はセッションの後続のすべてのパケットを SPU に転送して、フラグメント化されたパケットを含むセッションのパケットの順序を確認します。
IOC から NPC へのマッピングの設定
入出力カード (IOC) からネットワーク処理カード (NPC) へのマッピングでは、1 つの IOC を 1 つの NPC にマッピングする必要があります。ただし、複数の IOC を 1 つの NPC にマッピングできます。SRX3400上のNPCとSRX3600サービス ゲートウェイの処理能力のバランスを取るために、シャーシ プロセス(デーモン)はマッピングを実行するアルゴリズムを実行します。マッピングされた IOC の量が最も少ない NPC に IOC をマッピングします。コマンドライン インターフェイス(CLI)を使用して、特定の IOC を特定の NPC に割り当てることもできます。マッピングを設定すると、シャーシ プロセスは最初に設定を使用し、次に残りの IOC に最小番号 NPC アルゴリズムを適用します。
プラットフォームのサポートは、インストールされた Junos OS のリリースによって異なります。
IOC から NPC へのマッピングを設定するには:
[edit]
set chassis ioc-npc-connectivity {
ioc slot-number npc (none | slot-number);
}
set chassis ioc-npc-connectivityオプションの説明については、表 2 を参照してください。
オプション |
形容 |
|---|---|
IOCの slot-number |
IOCスロット番号を指定します。範囲は、SRX3400デバイスの場合は 0 〜 7、SRX3600 デバイスの場合は 0 から 12 です。 |
NPC slot-number |
NPCスロット番号を指定します。範囲は、SRX3400デバイスの場合は0〜7、SRX3600およびSRX 4600デバイスの場合は0〜12です。 |
何一つ |
シャーシプロセスは、特定のIOCの接続をマッピングします。 |
set chassis ioc-npc-connectivityコマンドをコミットした後、シャーシ制御を再起動する必要があります。
SRX5K-SPC3 デバイスでのフロー処理について
サービス処理カード SRX5K-SPC3 は、SRX5000 セキュリティ サービス ゲートウェイにおけるセキュリティ サービスのパフォーマンスを向上させるために導入されました。SPC3カードは、より高いスループットをサポートし、シャーシクラスタの機能とサービス処理のための拡張性を維持するため、信頼性を維持します。
SPC3 カードは、次のセキュリティ機能をサポートしています。
アプリケーション層ゲートウェイ(ALG)。[ ALGの概要を見る]
高度なアンチマルウェア(Juniper ATP Cloud)[ Juniper Sky Advanced Threat Prevention管理を参照]
アプリケーションセキュリティスイート。[ セキュリティデバイス向けアプリケーションセキュリティユーザーガイドを参照]
フローベースのパケット処理の実装
GPRS トンネリング プロトコル (GTP) とストリーム制御伝送プロトコル (SCTP)。[ セキュリティデバイス向け汎用パケット無線サービスユーザーガイドを参照]
高可用性(シャーシ クラスタ)。[ SRXシリーズデバイス用シャーシ クラスタ ユーザー ガイドを参照]
侵入検出と防御(IDP)。[侵入 検出および防止の概要を参照してください]
ネットワーク アドレス変換(NAT)。[ セキュリティデバイスネットワークアドレス変換ユーザーガイドを参照]
ステートフルファイアウォール
SSL プロキシー。[ SSLプロキシを参照]
ファイアウォールユーザー認証。[ セキュリティデバイス向け認証および統合ユーザーファイアウォールユーザーガイドを参照]
コンテンツセキュリティ(ウイルス対策、Webフィルタリング、コンテンツフィルタリング、スパム対策)。[ セキュリティデバイスに関するUTMユーザーガイドを参照]
セキュリティ フローは、SPC2 カードでサポートされているすべての既存のセキュリティ機能で SPC3 カードをサポートするように拡張されています。
Junos OS リリース 18.2R1-S1 の SPC3 カードには、以下の制限が適用されます。
SPC3 カードと SPC2 カードの相互運用性はサポートされていません。
IPSec VPN機能は、SPC3カードではサポートされていません。
Junos OS リリース 18.2R1-S1 以降、SRX5000シリーズ デバイス用の新しいサービス処理カード(SPC3)が導入されました。新しいカードの導入により、デバイスの拡張性とパフォーマンスが向上し、シャーシクラスタの機能が維持されるため、信頼性が維持されます。SPC3カードは、サービス処理においてより高いスループットと拡張性をサポートします。
SRX5000シリーズ デバイスでは、SPC3カードは、I/Oカード(IOC2、IOC3)、スイッチコントロールボード(SCB2、SCB3)、ルーティングエンジン、SPC2カードと相互運用できます。
Junos OS リリース 18.4R1 以降では、SRX5000シリーズ デバイスで SPC3 カードと SPC2 カードの混在がサポートされます。
SRX5000シリーズにSPC3カードを追加する場合、新しいSPC3カードはSPCの最も小さい番号のスロットに取り付ける必要があります。SPC3カードは、元の一番小さい番号のスロットに取り付けられており、混合モードで中央点(CP)機能を提供します。 たとえば、サービス ゲートウェイに SPC2 カードと SPC3 カードが混在している場合、SPC3 はシャーシ内の SPC の中で最も小さい番号のスロットを使用する必要があります。この設定により、混合モードでの中央点(CP)機能がSPC3カードによって実行されるようになります。
混合モードで動作する SRX5000シリーズ デバイスでは、フロー処理は SPC3 カードと SPC2 カード間で共有されます。中央点処理は、SPC3 カードが取り付けられている最小番号の SPC スロットで行われます。
SRXシリーズファイアウォールがシャーシクラスタモードで動作している場合、SPC3カードとSPC2カードを各シャーシの同じスロット場所にインストールする必要があります。
- SPC3 ソフトウェア アーキテクチャについて
- 荷重分散の理解
- NP セッションとサービス オフロード (SOF) について
- SPC3 での J-Flow サポートについて
- データパス デバッグ SPU サポート(E2E)について
- フラグメンテーション処理、ISSU、および ISHU サポートについて
SPC3 ソフトウェア アーキテクチャについて
SPC3フローアーキテクチャはCP-Liteアーキテクチャと同じです。SPC3 には物理的に 2 つの SPU(サービス処理ユニット)があり、各 SPU には 2 つの CPU があります。
1 つまたは 2 つの SPC3 をインストールすると、トラフィック処理は最初の SPC の 75% を使用します。SPC3 を 3 つ以上インストールすると、トラフィック処理は最初の SPC の 50% を使用します。
IOC がパケットをハッシュしてフローを処理する方法が変更されました。図は、SPC3を搭載したSRXシリーズファイアウォールのパケットフローを示しています。
のパケット フロー
SPC3では、パケットはIOCから各コアに直接配信されます。IOC はフローされた RT スレッドにパケットを直接ハッシュするため、元の LBT スレッドは削除されます。これで、パケットは SPU ではなくフロード スレッドに配信されます。セキュリティ フローが SPU ID の代わりに NP セッションをインストールする場合、IOC はセッション スレッド ID を使用して、セッションに関連付けられた正しいスレッドにパケットを転送します。
を通過するパケット フロー
荷重分散の理解
収益ポートを通過するすべてのパケットは、CP-Liteアーキテクチャに基づく既存のSRX5000回線デバイスのハッシュと同じハッシュアルゴリズムに基づいて、異なるSPUに分散されます。ハッシュ方式は、トラフィックの種類によって異なります。以下の表は、ハッシュ方式の一覧です。
議定書 |
ポート |
ハッシュ方式 |
|
|---|---|---|---|
TCPの
|
L4送信元ポートと宛先ポート |
5 タプルでハッシュ化 |
|
UDP |
正常 |
L4送信元ポートと宛先ポート |
5 タプルでハッシュ化 |
GTPの |
L4送信元ポートと宛先ポート |
5 タプルでハッシュ化 |
|
IKE |
L4送信元ポートと宛先ポート
|
IPペアでハッシュ |
|
ICMP |
|
ICMP 情報は 5 タプルでハッシュされます。 ICMP エラーは 3 タプルでハッシュされます (ポート情報なし) |
|
SCTPの |
L4送信元ポートと宛先ポート |
5 タプルでハッシュ化 |
|
ESP |
SPI |
IPペアでハッシュ |
|
あら |
SPI |
IPペアでハッシュ |
|
GRE |
PPTP alg が有効になっている場合、sport = call id;dport = 0 デフォルトでは、ポートは0x00010001です |
3 タプルでハッシュ化 |
|
PIM |
デフォルトでは、PIM ポート0x00010001 |
3 タプルでハッシュ化 |
|
断片 |
最初のフラグメントには、通常のポートがあります 最初のフラグメントなし、ポートなし |
3 タプルでハッシュ化 |
|
その他の IP パケット |
ポート0x00010001 |
3 タプルでハッシュ化 |
|
IP なし |
該当なし |
Macアドレスとイーサネットタイプ(VLAN ID)でハッシュ |
|
NP セッションとサービス オフロード (SOF) について
ネットワーク プロセッサ(NP)セッションは、SPU セッションを許可および確立する IOC ベースのセッションです。NP セッションを通過するパケットには、次の利点があります。
パフォーマンス向上のために SPU でのセッション検索を回避します。
セッションSPUとハッシュSPU間の余分なパケット転送を回避します。
サービス オフロードは、基本的なファイアウォール サービスを必要とするセッションに低遅延機能を提供する特殊なタイプの NP セッションです。IOC の SOF セッションにヒットしたパケットは、SPU でのパケット処理をバイパスし、IOC によって直接転送されます。次のトラフィックタイプは、サービスのオフロードをサポートしています。
基本的なファイアウォール(プラグインとフラグメントなし)、IPv4およびIPv6 TCP、UDPトラフィック
IPv4 NAT
1ファンインおよび1ファンアウトマルチキャスト
FTPデータセッションなどのALG
SPC3 での J-Flow サポートについて
J-Flowは、業界標準のトラフィック監視メカニズムのジュニパーバージョンです。ネットワークトラフィック統計のスナップショットをリモートサーバーにエクスポートして、ネットワークの監視とさらなるデータ処理を行う機能を提供します。J-Flowはv5、v8、v9フォーマットをサポートしています。これら 3 つのバージョンはすべて SPC3 でサポートされています。
データパス デバッグ SPU サポート(E2E)について
データパス デバッグは、SRX5000 回線デバイスでフィルター ベースのエンドツーエンド(E2E)パケット デバッグ機能を提供します。パケット パスをトレースし、パケットの内容をダンプします。
SPC3 では、JEXEC がサポートされる唯一の E2E イベント タイプであり、次の E2E アクション タイプがサポートされています。
数える
ダンプ
跡
トレースサマリー
フラグメンテーション処理、ISSU、および ISHU サポートについて
SPC3 では、フラグメント化されたパケットは、ヘッダー タプル値に基づいて特定の PFE の「フラグメント コア」に転送されます。フラグメント化されたパケットを受信した後、フローは最適化を実行し、パケットをセッションコアに転送します。制御ロジックは変更されず、同じままです。
ISSU の実行中、仮想 SPU は関連する仮想 SPU ID に同期されます。ISHU サポートは、CP-Lite アーキテクチャに基づいています。基本的に、次の 2 つの ISHU 操作がサポートされています。
新しいSPCをセカンダリノードに挿入します。
セカンダリ ノードの SPC を交換し、SPC の数はプライマリ ノードの数と同じにする必要があります。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。