ジュニパーの耐障害性インターフェイス

ルーティング パス上で隣接するネットワーク要素または隣接デバイスに転送する必要があるパケットは、いくつかの要因により、ルーターによって破棄される場合があります。どのネットワークでも、パケットロスなどの問題は時々発生します。トラフィックの損失やデータパケットの送信ブロックの原因としては、システムの過負荷状態、トラフィックの帯域幅や優先度を制限するプロファイルやポリシー、ネットワークの停止、物理的なケーブル障害による混乱などが挙げられます。パケット損失は、転送パスの誤ったステッチや、コントロールプレーンの状態とデータプレーンの状態の不一致によっても発生します。 show コマンドのカウンターとメトリックを使用して、ネットワークパフォーマンスを診断およびデバッグすることもできますが、それには面倒で時間がかかる場合があります。JRIは、パケットドロップに遭遇したシステム内のエンティティからの例外データを報告するため、有害な例外の検出、報告、軽減に関連するワークフローを自動化できます。

オペレーティング システム例外とルーティング例外の場合、例外データはテレメトリのキーと値のペアで報告されます。

転送例外の場合、例外データは IPFIX パケットで報告されます。IPFIX プライマリ データ レコードの IE は、次のデータを入力します。

• 例外の理由 (ファイアウォールの破棄など)
• パケット方向(イングレスまたはエグレス)
• パケットの最初の N バイト
• イングレスインターフェイス
• エグレスインターフェイス
• ネクストホップ識別子(Junos OSのみ)

表1 は、ジュニパー固有のIEを使用したIPFIXプライマリデータレコードのフォーマットを示しています。

制限：

• 例外はベストエフォートベースで収集され、エクスポートされます。

• JRIはインライン監視サービスを使用してパケットをサンプリングおよび収集するため、インライン監視サービスに関する制限または注意事項はJRIにも適用されます。

• すべてのドロップされたパケットをサンプリングしてプロファイリングすることはできません。例外のクラスは、[edit services inline-monitoring instance instance-name collector collector-name]階層レベル(Junos OS)または[edit services inline-monitoring instance instance-name]階層レベル(Junos OS Evolved)のいずれかでsampling-rateステートメントで設定しない限り、デフォルトのサンプリングレートでサンプリングされます。Junos OSでは、サンプリングレートをコレクターごとに設定することができ、コレクターごとに異なるレートを可能にします。Junos OS Evolvedでは、インライン監視インスタンスごとに1つのサンプリングレートを使用できます。

• エグレス方向の例外報告では、レイヤー 2 またはトンネルのカプセル化の前に例外が発生するため、レイヤー 2 ヘッダーまたはカプセル化ヘッダーは IE-315、dataLinkFrameSelection に含まれません。

• エグレス方向の例外報告では、フィールドに正しい値がないため、IPFIX パケットの受信者は IE-312, dataLinkFrameSize を無視する必要があります。

• エグレス方向では、同じインターフェイス上でsFlowと例外レポートの両方を設定することはできません。

• インラインモニタリングインスタンスアクションとファイアウォールリダイレクトインスタンスアクションは、ファイアウォールフィルターの同じ条件ではサポートされていません。(Junos OS Evolved)

• インライン監視インスタンスアクションとポートミラーリングインスタンスアクションは、ファイアウォールフィルターの同じ条件ではサポートされていません。(Junos OS Evolved)

• コレクターの場合、ルーティング インスタンス、DSCP ビット、または転送クラスを設定することはできません。 (Junos OS Evolved)

• 注意事項や制限事項など、ジュニパー固有のIEの詳細については、 primary-data-record-fieldsを参照してください。

このセクションでは、Junos OSとJunos OS Evolvedの両方の例外コードとその説明について説明します。

• MX 例外コード、Junos OS
• PTXシリーズ例外コード、Junos OS Evolved