Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

セッションに関するMPLS収集

統計収集のための MPLS の設定

送信セッションを含むすべての MPLS セッションに関するトラフィック統計情報を定期的に収集するように MPLS を設定statisticsできます。文を設定します。MPLS 管理情報ベースstatistics (mib) の SNMP ポーリングを使用して MPLS トラフィック統計情報を収集する場合は、このステートメントを設定する必要があります。

MPLS 統計情報の収集を有効または無効statisticsにするには、以下のステートメントを含めます。

これらのステートメントは、以下の階層レベルで設定できます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

デフォルト間隔は300秒です。

このfileオプションを設定した場合、統計はファイルに格納されます。1つのエントリは LSP ごとに存在します。指定された期間中に、以下の情報がこのファイルに記録されます。

  • 各 LSP によって送信されるパケット数、バイト数、パケット数/秒、および 1 秒あたりのバイト数。Junos OS リリース 11.1 R2、11.2 R2、11.4 では、Trio チップセットを使用した、サブ Junos Lsp のパケットおよびバイト統計情報の表示用のパリティがサポートされています。

  • 特定の LSP で、その LSP に設定されている帯域幅の割合に関連して送信される帯域幅の比率。LSP に帯域幅が設定されていない場合は、0パーセントがパーセンテージ列に記録されます。

各定期レポートの最後には、現在の時刻、セッション数の合計、読み取りセッション数、セッション数、無視されている場合は、読み取りエラーなどが表示されます。通常、無視されたセッションは、アップ状態ではない、または予約済み(0~15)の受信ラベル(通常は LSP のエグレス ポイント)を持つセッションです。読み取りエラーの理由は、エラーが発生した LSP のエントリと同じ行に表示されます。統計の収集は信頼性の低いプロセスです。ときどき読み取りエラーが発生すると、その精度に影響を及ぼす可能性があります。サンプル出力は以下のとおりです。

UHP Lsp の概要におけるオンデマンドパケット損失および遅延測定

このトピックでは、ネットワークパフォーマンスの監視を可能にする MPLS ネットワーク内のポイントツーポイントの最終ホップポップ (UHP) ラベル交換パス (Lsp) のパケットロス、遅延、スループットを測定する方法について説明します。

パケットロスと遅延を測定することの重要性

IPTV やモバイル動画など、帯域幅を消費するアプリケーションの増加と、ビット当たりのコストを最小限に抑え、1ビット当たりの価値を最大化するというプレッシャーにより、キャリアは回線ベースの技術からトランスポートネットワークに移行し、パケットベースの技術。MPLS は、パケットベースのトランスポートネットワークに最適な接続指向のパケットトランスポート技術です。

データネットワークに新しいアプリケーションが登場したことで、サービスプロバイダは新しいアプリケーションの展開による影響を正確に予測することがますます重要になってきています。ネットワークのネットワークパフォーマンスを理解し、モデリングすることは、導入を成功させるために新しい世界のアプリケーションを導入する場合に特に重要です。パケットネットワークでは、パフォーマンスの最も基本的な指標として、パケットロスと遅延が2つあります。エンドツーエンドの測定に関しては、彼らの役割はさらに重要です。

ほとんどのエンドツーエンドのユーザーアプリケーションに属するトラフィックは、機密性の低下 (ファイル転送)、遅延 (音声またはビデオアプリケーション)、またはその両方 (インタラクティブなコンピューティングアプリケーション) のいずれかになります。サービスプロバイダのサービス品質保証契約 (Sla) は、Sla が直接的または間接的に損失に依存し、サービスプロバイダーで顧客のトラフィックエクスペリエンスを遅延させるために、これらのネットワークパフォーマンスメトリックを測定して監視する機能に依存しています。ネットワーク.

SLA への準拠を保証するために、サービスプロバイダは、パフォーマンスメトリックを測定および監視し、パケットロス、一方向の遅延、双方向の遅延、さらには遅延の変動やチャネルスループットなどの関連メトリックを確認するツールを必要としています。この測定機能により、サービスプロバイダは、ネットワークのパフォーマンス特性をより詳細に把握できるため、計画、トラブルシューティング、ネットワークパフォーマンスの評価を容易に実現できます。

パケット損失、遅延、スループットの定義

パケットネットワークでは、パフォーマンスの最も基本的な指標として、パケットロスと遅延が2つあります。

  • Loss:パケット損失は、送信された 1 つ以上のパケットが宛先に到着障害となります。パケットロスとは、輻輳を管理するためにネットワークによって破棄されたデータのパケットを指します。

    データアプリケーションは、通常は時間が区別されず、破棄されたパケットを再送できるため、パケット損失に対して非常に高い耐性があります。しかし、ビデオ会議環境や、VoIP などの音声通信では、パケットロスによってジッターが発生することがあります。

  • Delay:パケット遅延(遅延とも呼ばれる)とは、銅線、光ファイバー、電波などの伝送媒体の速度、ルーターやモデムなどのデバイスによる伝送の遅延に応じて、データのパケットが指定された地点から別の地点に移動するのにかかる時間です。

    低レイテンシは、ネットワークの効率が高いことを示します。

  • Throughput:パケット遅延とは、アクションの開始から完了までを示す時間を測定します。一方、スループットは一度に発生するこのようなアクションの総数です。

パケット損失と遅延の測定メカニズム

パケット遅延と損失は、ネットワークパフォーマンスの2つの基本指標です。Junos OS は、オンデマンドメカニズムを提供してパケットロスを測定し、関連する双方向 MPLS 最終ホップポップ (UHP) ラベル交換パス (Lsp) を遅延させることができます。

オンデマンド遅延およびパケットロスの測定メカニズムは、以下の CLI コマンドを使用して開始されます。

  • monitor mpls loss rsvp:関連付けられた双方向 UHP LSP のオンデマンド損失測定を実行します。

  • monitor mpls delay rsvp:関連する双方向 UHP LSP のオンデマンド遅延測定を実行します。

  • monitor mpls loss-delay rsvp:関連する双方向 UHP LSP について、オンデマンドで組み合わせた損失および遅延測定を実行します。

遅延とパケットロスのメカニズムを開始するには、測定に必要なパラメーター (計測タイプや LSP 名など) を入力する必要があります。パラメーターを受け取ると、パフォーマンス監視データの要約が表示され、メカニズムが終了します。

パケットロスと遅延メトリック

以下のパフォーマンスメトリックは、オンデマンドパケット損失および遅延メカニズムを使用して測定されます。

  • 損失測定 (パケットおよびオクテット)

  • スループット測定 (パケットおよびオクテット)

  • 双方向チャネル遅延

  • ラウンドトリップ遅延

  • パケット遅延の偏差 (IPDV)

このmonitor mpls loss rsvpコマンドは、損失とスループットの測定を実行monitor mpls delay rsvpし、コマンドは2方向のチャネル遅延、ラウンドトリップ遅延、ipdv 測定を実行します。このmonitor mpls loss-delay rsvpコマンドは、統合された損失と遅延の計測を実行し、上記のパフォーマンスメトリックをすべて同時に測定します。

パケット損失と遅延の測定の概念

パケットロスと遅延の機能をより深く理解するには、以下の内容を参考にしてください。

  • Querier—クリーアは、損失または遅延測定のためのクエリ メッセージを発信するイングレス プロバイダ エッジ(PE)ルーターです。

  • Responder—レスポンダーはエグレス PE ルーターで、クエリアからクエリー メッセージを受信して応答します。

  • Associated bidirectional LSP:関連付けられた双方向 LSP は、両方の LSP エンド ポイント上の設定を介して結びつけられる(または互いに関連付けられている)2 つの一方向 LSP で構成されます。

    オンデマンド損失と遅延測定は、関連付けられた双方向の双方向 UHP Lsp でのみ実行できます。

  • Generic associated channel (G-Ach):パフォーマンス監視メッセージにより、G-Ach 上でオンデマンドで損失と遅延測定フローをMPLSします。このタイプのチャネルは、インバンドの応答のみをサポートし、アウトオブバンドまたは非応答モードのサポートは行いません。

  • Measurement point (MP):MP は、測定の条件が記述された場所です。

    転送側でパケットロスを発生させるための MP は、スイッチングファブリックと送信インターフェイスの間にあります。このカウンター値は、ハードウェアの損失測定メッセージにスタンプされてから、伝送キューに入れられます。

    受信側でパケットロスを発生させるための MP は、受信インターフェイスとスイッチングファブリックの間にあります。MP は受信側で配布されています。さらに、送信インターフェイスが集約インターフェイスである場合は、MP も同時に配布されます。

  • Query rate—クエリー レートは、損失と遅延測定のために送信される 2 つのクエリー間の間隔です。

    損失と遅延の測定メッセージはルーティングエンジンから発信されるため、複数のチャネルのクエリレートが高いと、ルーティングエンジンに大きな負荷がかかります。サポートされている最小クエリ間隔は1秒です。

    データトラフィックレートが非常に高くなると、カウンターがすぐにラップされる可能性があるため、クエリレートは32ビットのカウンターでは高いものにする必要があります。損失測定に関わる4つの測定ポイントの位置で、64ビットのカウンターが使用されている場合は、クエリーレートを低くすることができます。Junos OS は、64ビットのカウンターのみをサポートしています。

  • Traffic class—デフォルトでは、チャネル全体で損失測定がサポートされています。Junos OS は、トラフィッククラスごとにデータトラフィック統計情報を保持するカウンターを作成する必要がある場合に、トラフィッククラスの範囲にあるパケット損失測定もサポートします。

    トラフィックごとのクラスカウンターは、デフォルトでは作成されません。トラフィッククラススコープ損失測定を構成するにはtraffic-class-statistics 、階層レベル[edit protocols mpls statistics]のステートメントを含めます。

    traffic-class-statistics設定されている場合、その中のコントロールパケットが送信および受信カウンターにカウントされることはありません。

    注:

    トラフィッククラス統計を有効または無効にすると、Lsp のすべてのカウンター (集約カウンターおよびクラス単位のカウンター) がリセットされます。

  • Loss measurement mode:Junos OSダイレクト モードのオンデマンド損失測定をサポートし、推論モードはサポートしません。

    直接的な損失を測定するには、関連する双方向 LSP の2つの単一方向 lsp の受信と送信でデータトラフィック統計を維持する必要があります。MX シリーズルーターが MPCs と Mic のみを使用している場合、データトラフィック統計情報を維持するためのカウンターは、すべてのタイプの Lsp を受信し、UHP Lsp を送信すると、デフォルトで作成されます。

    ただし、次の理由により、損失の直接測定は完全に正確ではありません。

    • ハードウェアのパラレル転送の特性。

    • アグリゲート型イーサネットインターフェイスなど、ネットワーク内の同等コストのマルチパス (ECMP) が存在する場合、損失の測定メッセージを基準にしてデータパケットの再注文が発生する可能性があります。

    • このような期間を流れない制御パケットは LSP 受信でカウントされませんが、LSP 送信でカウントされます。

    • MPLS ネットワークと損失の測定範囲では、Diffserv が実装されたときの損失測定メッセージに関連したデータトラフィックの再注文は、トラフィッククラスを対象とした完全なチャネルです。

      この制限を克服するには、Diffserv が実装されているときに、トラフィッククラススコープ損失測定を実行します。

    注:

    LSP に関連付けられた受信または送信インターフェイスが変更されると、ダイレクトモード損失の測定が中断の影響を受けやすくなります。

  • Loss measurement synchronization:RFC 6374 のセクション 2.9.8 で指定されている同期条件は、絶対意味では当てはめ手ではありません。ただし、損失測定カウンターがハードウェアにスタンプされると、同期条件を満たしていないことによって発生したエラーは比較的小さくなります。これらのエラーは定量化する必要があります。

    LSP の送信/受信インターフェイスが集約インターフェイスである場合、そのインターフェイスが非集約インターフェイスである場合と比較して、さらに多くのエラーが発生します。いずれの場合も、損失測定カウンターはハードウェアにスタンプされ、エラーを定量化する必要があります。

  • Delay measurement accuracy:送受信インターフェイスが異なるパケット転送エンジン上に存在する場合、これらのパケット転送エンジンでクロックを同期して、二方向の遅延測定を行う必要があります。この条件は、オンデマンド遅延測定機能が実装されているプラットフォームに当てはまります。

    集約インターフェイスまたは ECMP が存在する場合、遅延は、潜在的なパスの1つに対してのみ測定されます。

    結合損失と遅延メッセージが遅延計算に使用されている場合、送信または受信インターフェイスが集約インターフェイスである場合など、場合によっては遅延の測定メッセージが使用された場合とは比較の精度が低くなります。

    遅延測定は常にトラフィッククラス単位で実行され、テスト後に測定の精度を定量化する必要があります。

  • Timestamp format—Junos OS遅延測定メッセージを記録IEEE 1588 Precision Time Protocol(PTP) [IEEE1588] フォーマットのみをサポートしています。ネットワーク時刻形式 (NTP) はサポートされていません。

  • Operations, administration, and maintenance (OAM)MPLS LSP に対するすべての OAM メッセージが MPLS G-Ach をフローし、MPLS パフォーマンス監視メッセージを MPLS G-Ach 上で送信するには、ステートメントを階層レベルで含める必要があります。 oam mpls-tp-mode[edit protocols mpls label-switched-path lsp-name]

パケット損失と遅延の測定機能

図 1は、パケットロスと遅延の双方向の測定に使用する基本的な方法を示しています。2台のルーター、ルーター A とルーター B の間には双方向チャネルが存在します。T1、T2、T3、T4 の一時的な参照ポイントは、ルーター A で行なう測定操作と関連付けされています。この操作は、ルーター A がルーター B にクエリ メッセージを送信し、ルーター B が応答を返すという処理で構成されます。各基準点は、照会または応答メッセージがチャネルを介して送信または受信された時点を示します。

図 1: 基本的な双方向測定基本的な双方向測定

ルーター 図 1a では、ルーター B に損失測定クエリメッセージを送信することで、前方および逆方向にチャネルを通過するパケットロスを測定できます。Forward および reverse の各メッセージには、ルーター B (A_TxP) へのチャネルを介して、時間 T1 より前に送信されたパケット数が含まれています。

メッセージがルーター B に到達すると、メッセージに2つの値が付加され、メッセージがルーター A に反映されます。この2つの値は、チャネルでルーター A (B_RxP) からの時間 T2 より前に受信したパケット数と、ルーター A (B_TxP) へのチャネル経由でのタイム T3 より前に送信されたパケット数の合計です。

応答がルーター A に到達すると、4 つ目の値がメッセージの末尾に追加されます。これは、ルーター B(プロトコル間)からチャネルをめぐって T4 が受信される前に受信したパケット数A_RxP。

これらの 4 つのカウンター値(A_TxP)、(B_RxP)、(B_TxP)、(A_RxP)、および (A_RxP)、ルーター A で望ましい損失統計を計算できます。ルーター A の送信数とルーター B の受信数 (またはその逆) が最初のメッセージ時に同期されない可能性があり、また、カウンターラップの影響を制限しないと、損失はメッセージ間のデルタの形で計算されます。

メッセージ「LM [n-1]」および LM [n] に示された測定間隔内で送信損失 (A_TxLoss [n-1, n]) および受信損失 (A_RxLoss [n-1, n]) は、以下のようにルーター A によって計算される。

  1. A_TxLoss [n-1, n] = (A_TxP [n]-A_TxP [n-1])-(B_RxP [n]-B_RxP [n-1])

  2. A_RxLoss [n-1, n] = (B_TxP [n]-B_TxP [n-1])-(A_RxP [n]-A_RxP [n-1])

この計算は、カウンターサイズの剰余です。

ルーター a からルーター B へのチャネルの遅延を通過するように測定するには、遅延測定クエリメッセージがルーター A からルーター B に送信されます。これは、タイムスタンプが含まれていて、それが送信される瞬間を記録しています。で図 1は、タイムスタンプは T1 に記録されています。

メッセージがルーター B に到達すると、タイムスタンプが追加され、受信した瞬間 (T2) の記録が書き込まれます。このメッセージはルーター b からルーター A へと転送され、ルーター B は送信タイムスタンプ (T3) とルーター A を追加して受信 timestamp (T4) を追加することができるようになりました。

T1、T2、T3、T4 の 4 つのタイムスタンプにより、ルーター A は、一方向の遅延とチャネルの二方向の遅延を計算できます。一方向の遅延計算では、ルーター A と B のクロックを同期する必要があります。

ルーター A は、この時点で、チャネルに関連付けられた双方向チャネル遅延とラウンドトリップ遅延を次のように計算できます。

  1. 双方向チャネル遅延 = (T4-T1)-(T3-T2)

  2. ラウンドトリップ遅延 = T4-T1

パケットロスと遅延の機能

Supported Features of Packet Loss and Delay

Junos OS は、オンデマンド損失および遅延測定によって以下の機能をサポートしています。

  • 関連する双方向 MPLS ポイントツーポイント UHP Lsp のみを対象としたパフォーマンス監視

  • 損失測定

  • スループット測定

  • 双方向遅延測定 (チャネル遅延および往復遅延)

  • パケット遅延の偏差 (IPDV)

  • ダイレクトモード損失の測定

  • 集約型イーサネットと集約された SONET インターフェイス

  • マルチシャーシのサポート

  • 64ビット互換

Unsupported Features of Packet Loss and Delay

Junos OS は、以下のオンデマンド損失および遅延測定機能をサポートしていません。

  • 疑似ワイヤの損失と遅延測定 (RFC 6374 のセクション 2.9.1)

  • 単方向測定 (RFC 6374 のセクション 2.6)

  • Dyadic の測定 (RFC 6374 のセクション 2.7)

  • ループバックモードでの損失と遅延の測定 (RFC 6374 のセクション 2.8)

  • LSP エンドポイントから中間ノードへの損失と遅延測定 (RFC 6374 のセクション 2.9.5)

  • 外部の後処理 (RFC 6374 のセクション 2.9.7)

  • 推定モード損失の測定 (RFC 6374 のセクション 2.9.8)

  • プロアクティブモード

  • 論理システム

  • SNMP

例:オンデマンド損失と遅延測定の構成

この例では、ネットワークパフォーマンスを監視するために MPLS ネットワークのポイントツーポイントの最終ホップポップアップ (UHP) ラベル交換パス (Lsp) のオンデマンド損失と遅延測定を有効にする方法を示します。

要件

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

  • MPC/Mic のみを含む2つの MX シリーズ5G ユニバーサルルーティングプラットフォーム

  • すべてのルーターで Junos OS リリース14.2 以降を実行している場合

開始する前に:

  1. デバイスインターフェイスを構成します。

  2. デバイスの自律システム番号とルーター Id を設定します。

  3. 以下のプロトコルを構成します。

    • RSVP

    • MPLS

    • OSPF

概要

Junos OS リリース14.2 から開始し、関連づけられた双方向 MPLS のパケットロス、パケット遅延、またはその両方を監視して測定するオンデマンドツールである最終ホップポップ (UHP) ポイントツーポイントラベルスイッチパス (Lsp) が導入されています。このツールは、 の CLI コマンド monitor mpls loss rsvpmonitor mpls delay rsvp を使用して有効 monitor mpls loss-delay rsvp にできます。

これらのコマンドは、ダイレクトモードのパケット損失、双方向のパケット遅延、およびパケットの遅延の変動やチャネルスループットの測定など、関連メトリックのパフォーマンスメトリックのオンデマンド要約を提供します。

この機能により、ネットワークパフォーマンスをリアルタイムで可視化できるため、ネットワークのパフォーマンス計画、トラブルシューティング、評価を容易に実行できます。

Topology

図 2は、シンプルな2ルータートポロジを使用したオンデマンド損失と遅延測定を示しています。

図 2: オンデマンド損失と遅延測定の構成オンデマンド損失と遅延測定の構成

この例では、関連する双方向 LSP はルーター R1 と R2 の間で構成されており、パフォーマンスメトリックが測定されます。

構成

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細を変更し、コマンドを[edit]階層レベルで CLI にコピー & ペーストしてから設定commitモードから開始します。

R1

R2

手順

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。Cli のナビゲートの詳細については、『 Cli ユーザーガイド』の「 Cli エディターを設定モードで使用する」を参照してください。

ルーター R1 を構成するには、次のようになります。

  1. トンネルサービスと拡張 IP ネットワークサービス構成を使用してシャーシを有効にします。

  2. ルーター R1 のインターフェイスを構成します。

  3. ルーター R1 のルーター ID を構成します。

  4. 管理インターフェイスを除外して、ルーター R1 のすべてのインターフェイスで RSVP を有効にします。

  5. 管理インターフェイスを除外して、ルーター R1 のすべてのインターフェイスで MPLS を有効にします。

  6. 関連する双方向 LSP をルーター R2 に設定します。

  7. トラフィッククラスごとにデータトラフィック統計情報を保持するためのトラフィッククラスを作成します。

    これにより、トラフィッククラスの損失測定値が有効になります。

  8. トラフィックエンジニアリング機能を備えた OSPF を構成し、管理インターフェイスを除外したルーター R1 のすべてのインターフェイス上で OSPF を有効にします。

結果

構成モードからshow chassis、、、 show interfacesshow routing-options、およびshow protocolsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

検証

構成が正常に機能していることを確認します。

LSP ステータスの確認

目的

ルーター R1 と R2 の間に関連する双方向 LSP が稼働していることを確認します。

アクション

動作モードから、 show mpls lspコマンドを実行します。

関連付けられた双方向の LSP R1-R2 が稼働し、アクティブになっています。

パケット損失測定の検証

目的

オンデマンド損失の測定結果を確認します。

アクション

動作モードから、 monitor mpls loss rsvp R1-R2 count 2 detailコマンドを実行します。

2つのカウントのパケット損失測定値が表示されます。

パケット遅延測定の確認

目的

オンデマンドの遅延測定結果を確認します。

アクション

動作モードから、 monitor mpls delay rsvp R1-R2 count 2 detailコマンドを実行します。

2つのカウントのパケット遅延測定値が表示されます。

パケットロスの検証-遅延の測定

目的

オンデマンド損失と遅延測定の結果を検証します。

アクション

動作モードから、 monitor mpls loss-delay rsvp R1-R2 count 2 detailコマンドを実行します。

パケットロスと遅延の測定値が2つ表示されます。

例:双方向 MPLS Lsp のプロアクティブ損失と遅延測定の設定

次の例は、ネットワークパフォーマンスを監視するために MPLS ネットワーク内のポイントツーポイントの究極のホップラベルスイッチパス (Lsp) に対して、プロアクティブな損失と遅延測定を構成する方法を示しています。

要件

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

  • MPC/Mic のみを含む2つの MX シリーズ5G ユニバーサルルーティングプラットフォーム

  • すべてのルーターで Junos OS リリース15.1 以降を実行している場合

開始する前に:

  1. デバイスインターフェイスを構成します。

  2. デバイスの自律システム番号とルーター Id を設定します。

  3. 以下のプロトコルを構成します。

    1. MPLS

    2. OSPF

    3. RSVP

概要

Junos OS リリース15.1 から開始して、関連する双方向 MPLS のパケットロス、パケット遅延、またはその両方を監視して測定するためのプロアクティブなツールです。最終ホップのポップポイントツーポイントのラベルスイッチパス (Lsp) が導入されています。

この機能により、以下のパフォーマンスメトリックが提供されます。

  • パケット遅延の偏差 (IPDV)

  • 損失測定

  • ラウンドトリップ遅延 (RTT)

  • スループット測定

  • 双方向チャネル遅延

この機能により、ネットワークパフォーマンスをリアルタイムで可視化できるため、ネットワークのパフォーマンス計画、トラブルシューティング、評価を容易に実行できます。

Topology

図 3は、シンプルな2ルータートポロジを使用して、プロアクティブな損失と遅延の測定を示しています。

図 3: プロアクティブな損失と遅延測定の設定プロアクティブな損失と遅延測定の設定

この例では、関連する双方向 LSP はルーター R1 と R2 の間で構成されており、パフォーマンスメトリックが測定されます。

構成

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細を変更し、コマンドを[edit]階層レベルで CLI にコピー & ペーストしてから設定commitモードから開始します。

R1

R2

手順

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。Cli のナビゲートの詳細については、『 Cli ユーザーガイド』の「 Cli エディターを設定モードで使用する」を参照してください。

ルーター R1 を構成するには、次のようになります。

  1. 拡張された IP ネットワークサービス構成を有効にします。

  2. ルーター R1 のインターフェイスを構成します。

  3. ルーター R1 のルーター ID を構成します。

  4. 管理インターフェイスを除外して、ルーター R1 のすべてのインターフェイスで RSVP を有効にします。

  5. 管理インターフェイスを除外して、ルーター R1 のすべてのインターフェイスで MPLS を有効にします。

  6. 関連する双方向 LSP をルーター R2 に設定します。

  7. トラフィッククラスごとにデータトラフィック統計情報を保持するためのトラフィッククラスを作成します。

    これにより、トラフィッククラスを対象とした損失と遅延の測定が可能になります。

  8. クエリ側でパフォーマンス監視を構成します。

  9. 応答側でパフォーマンス監視を構成します。

  10. トラフィックエンジニアリング機能を備えた OSPF を構成し、管理インターフェイスを除外したルーター R1 のすべてのインターフェイス上で OSPF を有効にします。

結果

構成モードからshow chassis、、、 show interfacesshow routing-options、およびshow protocolsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

検証

損失と遅延の測定

目的

損失と遅延の測定を確認します。

アクション

動作モードから、 show performance-monitoring mpls lspコマンドを実行します。

LSP のパケット損失および遅延測定メトリックが表示されます。

オンデマンド損失と遅延測定の構成

ネットワークパフォーマンスを監視するために、MPLS ネットワーク内のポイントツーポイントの最終ホップポップアップ (UHP) ラベル交換パス (Lsp) にオンデマンド損失と遅延測定を構成できます。monitor mpls loss rsvp、、およびmonitor mpls delay rsvp CLI コマンドはmonitor mpls loss-delay rsvp、ダイレクトモードのパケット損失、双方向のパケット遅延、および関連メトリック (パケット遅延の変動やチャネルスループットの測定など) に関するパフォーマンスメトリックのオンデマンド要約を提供します。

この機能により、ネットワークパフォーマンスをリアルタイムで可視化できるため、ネットワークのパフォーマンス計画、トラブルシューティング、評価を容易に実行できます。

開始する前に:

  1. デバイスインターフェイスを構成します。

  2. デバイスルーター ID を設定します。

  3. 以下のプロトコルを構成します。

    • RSVP

    • OSPF

      トラフィックエンジニアリング機能を有効にします。

    • MPLS

PE デバイスを構成するには、次のようにします。

  1. トンネルサービスと拡張 IP ネットワークサービス構成を使用してシャーシを有効にします。
  2. 関連する双方向 LSP をリモートルーターに設定します。
  3. トラフィッククラスごとにデータトラフィック統計情報を保持するためのトラフィッククラスを作成します。

    これにより、トラフィッククラスの損失測定値が有効になります。

プロアクティブな損失と遅延測定の設定

ネットワークパフォーマンスを監視するために、MPLS ネットワーク内のポイントツーポイントの究極のホップラベルスイッチパス (Lsp) に対して、プロアクティブな損失と遅延測定を設定できます。CLI show performance-monitoring mpls lspコマンドは、ダイレクトモードのパケット損失、双方向のパケット遅延、およびパケットの遅延の変動やチャネルスループットの測定など、関連するメトリックのパフォーマンスメトリックのサマリを提供します。

この機能により、ネットワークパフォーマンスをリアルタイムで可視化できるため、ネットワークのパフォーマンス計画、トラブルシューティング、評価を容易に実行できます。

この機能により、以下のパフォーマンスメトリックが提供されます。

  • パケット遅延の偏差 (IPDV)

  • 損失測定

  • ラウンドトリップ遅延 (RTT)

  • スループット測定

  • 双方向チャネル遅延

開始する前に:

  1. デバイスインターフェイスを構成します。

  2. デバイスの自律システム番号とルーター Id を設定します。

  3. 以下のプロトコルを構成します。

    • MPLS

    • OSPF

    • RSVP

PE デバイスでプロアクティブな損失と遅延測定を設定するには、次のようにします。

  1. 関連する双方向 LSP をルーター R2 に設定します。
  2. トラフィッククラスごとにデータトラフィック統計情報を保持するためのトラフィッククラスを作成します。

    これにより、トラフィッククラスを対象とした損失と遅延の測定が可能になります。

  3. クエリ側でパフォーマンス監視を構成します。
  4. 応答側でパフォーマンス監視を構成します。