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

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

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

転送例外の場合、例外データは IPFIX パケットで報告されます。IPFIX 1 次データ・レコード・パケット内の IES は、以下のデータをキャプチャーします。

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

表 1 は、ジュニパー固有の IE を使用した IPFIX 1 次データ・レコードの形式を示しています。

制限：

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

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

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

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

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

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

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

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

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

• ジュニパー固有の IE(注意事項や制限事項など)の詳細については、 プライマリデータレコードフィールドを参照してください。