Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

CEデバイスとPEデバイス間のCFM監視

このトピックでは、カスタマーエッジデバイスがジュニパーデバイスでない場合のプロバイダエッジデバイスとカスタマーエッジデバイス間のCFM監視について詳しく説明します。また、インターフェイスステータスTLV、ポートステータスTLV、シャーシID TLV、接続保護TLVがネットワーク監視にどのように役立つかについても、詳しく説明することができます。

CFMアクションプロファイル非同期通知

CFM 駆動の非同期通知により、それぞれの PE デバイスから発信される疑似ワイヤを介して相互に接続された 2 つの CE デバイス間のリンク ステータスの同期が可能になります。2台のCEデバイスが直接接続されているかのようにシナリオをエミュレートします。CFM は、PE1 と PE2 が単一のネットワークではなく、一連のネットワークを介して接続されている場合でも、エンドツーエンドのシグナリングを提供します。

PE1とPE2間のレイヤー2接続Network topology with BGP-based VPLS setup showing CE-1, CE-2, PE1, PE2, AGG-1, AGG-2, VPLS cloud, Layer 2 circuits, and CFM UP-MEP.

図1は、CFMベースの非同期通知を使用してCE1とCE2間のリンクステータスを同期する導入シナリオの例です。非同期通知の設定で満たすことができるのは、以下の2つの要件です。

  • PE2とCE2間のリンクがダウンすると、PE1とCE1間のリンクもダウンします。リンクが復元されると、PE1とCE1の間のリンクステータスが復元されます。PE1とCE1の間のリンクステータスの変更も同様に機能します。

  • PE1とPE2の間に接続上の問題が発生すると、PE1とCE1、PE2とCE2間のリンクダウンがトリガーされます。接続ステータスが回復すると、両端のリンクステータスが復元されるはずです。

非同期通知へのCFMアクションプロファイルの設定

PE1とPE2のCFM UP-MEPは、PE1とPE2間の接続を監視します。これらのUP-MEPエンドポイントの interface-status-tlv は、PE1、CE1、PE2間、およびPE2、CE2、PE1間のリンクステータスを伝達します。PE1からPE2でアクションプロファイルを設定して、それぞれのCEデバイスに向けて非同期通知を駆動する必要があります。アクションプロファイルは、受信した interface-status-tlvで隣接関係の損失またはリンクダウン状態をシステムが検出すると、これらの通知をトリガーします。

  1. インターフェイスレベルでasynchronous-notificationを有効にします。

    例えば

  2. アクションプロファイルと、アクションプロファイルをトリガーするCFMイベントを[edit protocols oam ethernet connectivity-fault-management]階層レベルで設定します。アクションプロファイルには複数のイベントを設定できます。

    例えば

    システムは、interface-status-tlv downinterface-status-tlv lower-layer-downadjacency-loss以外のイベントに対するasynchronous-notificationアクションをサポートしていません。その他のイベントを設定すると、コミットエラーがトリガーされます。

  3. asynchronous-notificationアクションを[edit protocols oam ethernet connectivity-fault-management action-profile profile-name]階層レベルで定義します。
  4. [edit protocols oam ethernet connectivity-fault-management]階層レベルでメンテナンスドメインを定義し、maintenance-associationパラメーターを指定します。

    例えば

  5. interface-status-tlvの生成を設定します。この設定は、interface-status-tlvに基づいてasynchronous-notificationを設定した場合に不可欠です。

    例えば

  6. [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name]階層レベルでmaintenance associationエンドポイントを定義し、関連するパラメーターを指定します。

    例えば

  7. RMEPレベルでasynchronous-notificationアクションプロファイルを設定します。

    例えば、

CEデバイスとPEデバイス間のCFM監視を理解する

カスタマーエッジデバイスがジュニパーデバイスではない場合、プロバイダエッジデバイスとカスタマーエッジデバイス間の接続障害管理(CFM)監視を有効にできます。インターフェイスがダウンすると、CFMはCCメッセージにインターフェイスのステータスを伝播します。CCメッセージは、プロバイダのエッジデバイスがダウンしていることをカスタマーエッジデバイスに通知します。

次の2つのオプションのいずれかを使用して、CFM監視を設定できます。

  • インターフェイスステータスTLV(タイプ、長さ、値)—カスタマーエッジデバイスがジュニパーデバイスではない場合、インターフェイスステータスTLVを使用することで、プロバイダエッジデバイスとカスタマーエッジデバイス間の接続障害管理(CFM)監視を有効にすることができます。インターフェイスがダウンすると、CFMはインターフェイスステータスTLVを使用してインターフェイスのステータスを伝播します。インターフェイスステータスTLVは、CCMを送信するMEPをホストするインターフェイスのステータスを示すか、IETF RFC 2863 IF-MIBの次に下位のインターフェイスを示します。これにより、顧客エッジデバイスは、プロバイダエッジデバイスがダウンしていることを学習します。インターフェイスステータスTLVを使用してCFM監視を設定するには、[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check階層レベルでinterface-status-tlvステートメントを使用します。この設定は標準オプションです。

  • RDI(Remote Defect Indication)—カスタマーエッジデバイスがジュニパーデバイスではない場合、RDIビットを使用することで、プロバイダエッジデバイスと顧客エッジデバイス間の接続障害管理(CFM)監視を有効にすることができます。CFM監視を有効にすると、CFMはCCメッセージのRDIビットを介してプロバイダエッジデバイスのステータスを伝播し、プロバイダエッジデバイスがダウンしていることを顧客エッジデバイスに通知します。RDI ビットは、サービスがバックアップされるとクリアされます。RDIビットを使用してCFM監視を設定するには、[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check階層レベルでinterface-status-send-rdiステートメントを使用します。このオプションは、顧客エッジデバイスがインターフェイスステータスTLVをサポートしていない場合に必要です。

注:

インターフェイスをCCCダウンに設定し、RDIを設定すると、デバイスからRDIビットが送信されます。CFMはインターフェイスのステータスを監視しません。

インターフェイスがスタンバイ状態でないときにCCCをダウンしてRDIを設定すると、デバイスのCCメッセージにRDIビットが含まれます。

RDIビットを使用した単一のアクティブマルチホーミングユースケース

2 つのプロバイダ エッジ デバイス(PE1 および PE2)と 2 つのカスタマー エッジ デバイス(CE1 および CE2)を含む次のトポロジーを考えてみましょう。PE1 はアクティブ状態で動作しますが、PE2 はスタンバイ状態を維持します。PE と CE の間で CFM ダウン MEP を設定すると、CFM は CCC がダウンしていることを検出し、システムは CC メッセージに RDI ビットを含めます。PE2 から CE2 への CC メッセージには、ブロックされた状態を示す RDI ビットが設定されています。PE2がアクティブになると、システムはCCMダウンステータスをクリアし、後続のCCメッセージからRDIビットを削除します。

RDIビットを使用したアクティブ/アクティブマルチホーミングのユースケース

2 つのプロバイダ エッジ デバイス(PE1 および PE2)と 2 つのカスタマー エッジ デバイス(CE1 および CE2)を含む次のトポロジーを考えてみましょう。PE1 はアクティブ状態で動作しますが、PE2 はスタンバイ状態を維持します。リンク接続を監視するためにPEとCEの間でCFMダウンMEPを設定しない場合、システムはCCメッセージにRDIビットを含めません。PE と CE の間で CFM ダウン MEP を設定すると、CFM は CCC がダウンしていることを検出し、システムは CC メッセージに RDI ビットを含めます。PE2 から CE2 への CC メッセージには、ブロックされた状態を示す RDI ビットが設定されています。PE2がアクティブになると、システムはCCMダウンステータスをクリアし、後続のCCメッセージからRDIビットを削除します。

ポートステータスTLVとインターフェイスステータスTLVの設定

TLV の概要

タイプ、長さ、値(TLV)は、PDU 内の可変長および/またはオプション情報をエンコードする方法として、CFM の IEEE 802.1ag 規格で説明されています。TLV は、特定のワードまたはオクテット境界にアライメントされません。TLV はパディングなしで互いに続きます。

表1は 、TLV形式を示しており、それが必須かオプションかを示しています。

表1:TLVのフォーマット

パラメータ

オクテット(シーケンス)

説明

タイプ

1

このフィールドは必須です。値が 0 の場合、それ以上のフィールド (長さまたは値) は続きません。値が 0 でない場合は、[長さ] フィールドが続く必要があります。

長さ

2–3

このフィールドは、[タイプ] フィールドが 0 でない場合にのみ必要です。タイプフィールドが0の場合は存在しません。長さフィールドの16ビットは、値フィールドのサイズをオクテット単位で示します。長さフィールドの値が0の場合、値フィールドがないことを意味します。

4

このフィールドの長さは、[長さ] フィールドで指定されます。これは省略可能であり、[タイプ] フィールドが 0 の場合、または [長さ] フィールドが 0 の場合は表示されません。

CFM PDU 用のさまざまな TLV

表2 は、さまざまなCFM PDUタイプについてIEEE 802.1agによって定義されたTLVのセットを示しています。各TLVは、Typeフィールドに割り当てられた固有の値によって識別できます。一部の「タイプ」フィールド値は予約されています。

表2:CFM PDUのさまざまなTLVのタイプフィールド値

TLVまたは組織

タイプフィールド

終了 TLV

0

送信者ID TLV

1

ポートステータスTLV

2

データTLV

3

インターフェイスステータスTLV

4

応答イングレスTLV

5

応答エグレス TLV

6

LTMエグレス識別子TLV

7

LTR エグレス識別子 TLV

8

IEEE 802.1用に予約済み

9時から30時まで

組織固有のTLV

31

ITU-T Y.1731で定義されています。

32から63

IEEE 802.1用に予約済み

64から255

すべてのTLVがすべてのタイプのCFM PDUに適用できるわけではありません。

  • CCM(Continuity Check Message)に適用可能なTLV:

    • 終了 TLV

    • 送信者ID TLV

    • ポートステータスTLV

    • インターフェイスステータスTLV

    • 組織固有のTLV

  • ループバックメッセージ(LBM)に適用可能なTLV:

    • 終了 TLV

    • 送信者ID TLV

    • データTLV

    • 組織固有のTLV

  • ループバック応答(LBR)に適用可能なTLV:

    • 終了 TLV

    • 送信者ID TLV

    • データTLV

    • 組織固有のTLV

  • リンクトレースメッセージ(LTM)に適用可能なTLV:

    • 終了 TLV

    • LTMエグレス識別子TLV

    • 送信者ID TLV

    • 組織固有のTLV

  • リンクトレース応答(LTR)に適用可能なTLV:

    • 終了 TLV

    • LTR エグレス識別子 TLV

    • 応答イングレスTLV

    • 応答エグレス TLV

    • 送信者ID TLV

    • 組織固有のTLV

現在、該当するCFM PDUでは以下のTLVがサポートされています。

  • 終了 TLV

  • 応答イングレスTLV

  • 応答エグレス TLV

  • LTR エグレス識別子 TLV

  • LTMエグレス識別子TLV

  • データTLV

オプションの追加TLVのサポート

以下の追加オプションTLVがサポートされています。

  • ポートステータスTLV

  • インターフェイスステータスTLV

MXシリーズルーターは、ポートステータスTLVとインターフェイスステータスTLVの設定をサポートしています。ポートステータス TLV を設定することで、運用担当者は CFM PDU でのポートステータス TLV の送信を制御できます。

設定情報については、次のセクションを参照してください。

ポートステータスTLV

ポートステータスTLVは、MACのステータスに関係なく、送信MEPが存在するブリッジポートが通常のデータを渡す能力を示します。このTLVの値は、表4に示すように、MEP変数enableRmepDefectによって決定されます。このTLVの形式を表3に示します。

ポートステータスTLV値の変更により、そのブリッジポートMEP CCMの送信が1回追加でトリガーされます。

表3:ポートステータスTLVフォーマット

パラメータ

オクテット(シーケンス)

タイプ = 2

1

長さ

2–3

値( 表4を参照)

4

表4:ポートステータスTLV値

ニーモニック

ポートを自由に通過する通常のデータ

psブロック済み

なし: enableRmepDefect = false

1

psアップ

はい: enableRmepDefect = true

2

MEP 変数 enableRmepDefect はブール変数です。MEPのメンテナンスアソシエーションによって監視されているサービスインスタンス上のフレームが、スパニングツリープロトコルとVLANトポロジー管理を使用してブリッジポートを通過できるかどうかを示します。次の場合、TRUEに設定されます。

  • ブリッジポートは、トラフィックが通過できる状態に設定されます。

  • ブリッジポートは、スパニングツリーの複数のインスタンスを実行しています。

  • MEPインターフェイスは、ブリッジングドメインに関連付けられていません。

ポートステータスTLVの設定

Junos OSは、ポートステータスTLVの設定サポートを提供し、CCM PDUでのTLVの送信を制御できます。Junos OS は、この設定を継続性チェック レベルで提供します。デフォルトでは、CCMにはポートステータスTLVは含まれません。ポートステータスTLVを設定するには、[edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check]階層レベルでport-status-tlvステートメントを使用します。

注:

ポートステータス TLV設定は、IEEE 802.1agによって義務付けられていません。Junos OS は、運用担当者に柔軟性を与えるために、この設定を提供しています。ただし、設定に関係なく、ポートステータスTLVのCCMを受信して処理します。

設定ステートメントの例を以下に示します。

次の2つの場合は、ポートステータスTLV送信を有効にすることはできません。

  • メンテナンスアソシエーションのMEPインターフェイスがブリッジタイプでない場合。

  • MEPが物理インターフェイス上に設定されている場合。

受信ポートステータスTLVの表示

Junos OSは、リモートMEPから最後に受信したポートステータスTLVを保存します。受信したポートステータス値が 表4に示す標準値のいずれかに対応していない場合、 show コマンドはそれを「不明」と表示します。次の例のように、 show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier コマンドを使用して最後に保存された受信ポートステータスTLV表示できます。

送信ポートステータスTLVの表示

Junos OSは、ローカルMEPから最後に送信されたポートステータスTLVを保存します。ポートステータスTLVの送信が有効になっていない場合、 show コマンドは「なし」と表示されます。次の例のように、 show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier コマンドを使用して最後に保存された送信ポートステータスTLV表示できます。

インターフェイスステータスTLV

インターフェイスステータスTLVは、CCMを送信するMEPが設定されているインターフェイス、またはIETF RFC 2863 IF-MIBの次に下位のインターフェイスのステータスを示します。この TLV の形式を 表 5 に示します。列挙された値を 表6に示します。

表5:インターフェイスステータスTLVフォーマット

パラメータ

オクテット(シーケンス)

タイプ = 4

1

長さ

2–3

値( 表6を参照)

4

表6:インターフェイスステータスTLV値

ニーモニック

インターフェイスのステータス

isUp

上へ

1

isDown

ダウン

2

テスト中

テスト

3

isUnknown

不明

4

は休止状態です

休止状態

5

存在なし

notPresent

6

isLowerLayerDown

lowerLayerダウン

7

注:

論理インターフェイスの動作ステータスがダウン状態(ステータス値2)から下位レイヤーのダウン状態(ステータス値7)に変化した場合、またはその逆の場合、LinkDown SNMPトラップは生成されません。例えば、VLANタグを使用して集合型イーサネットインターフェイスバンドルを設定し、運用停止状態にある物理インターフェイスをバンドルに追加した場合、その時点での集合型イーサネット論理インターフェイスバンドルの運用ステータスは下位レイヤーダウン(7)となります。インターフェイスに関連するMICをオフラインにすると、論理インターフェイスが下位レイヤーのダウン状態からダウン状態に移行するときに、LinkDownトラップは生成されません。

同様に、VLANタグ付きの集約型イーサネットバンドルに物理インターフェイスが追加され、集約型イーサネット論理インターフェイスが無効になっている別の例のシナリオを考えてみましょう。論理インターフェイスが無効になると、論理インターフェイスの動作ステータスがダウンに変わります。集合型イーサネットバンドルの一部である物理インターフェイスを無効にすると、集約型イーサネット論理インターフェイスの動作ステータスはダウンしたままになります。集合型イーサネット論理インターフェイスを再度有効にすると、その運用ステータスがダウンから下位レイヤーに変わります。この時点では、LinkDown SNMPトラップは生成されません。

インターフェイスステータスTLVの設定

Junos OSは、インターフェイスステータスTLVの設定サポートを提供します。これにより、事業者は、継続チェックレベルの設定を通じて、CCM PDUにおけるこのTLVの送信を制御することができます。

注:

この設定は IEEE 802.1ag によって義務付けられていません。むしろ、運用担当者に柔軟性を与えるために提供されています。Junos OSは、この設定に関係なく、インターフェイスステータスがTLVのCCMを受信して処理します。

インターフェイスステータスTLV設定を以下に示します。

注:

Junos OSは、インターフェイスステータスTLVの7つの値のうち3つの値のみの送信をサポートしています。サポートされている値は1、2、7です。ただし、Junos OSは、インターフェイスステータスTLVの任意の値を受信できます。

受信したインターフェイスステータスTLVを表示します

Junos OSは、最後に受信したインターフェイスステータスTLVをリモートMEPから保存します。受信したインターフェイスステータス値が 表5に示す標準値のいずれにも一致しない場合、 show コマンドは「不明」と表示されます。

次の例のように、この最後に保存されたインターフェイスステータスTLV show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier コマンドを使用して表示できます。

送信されたインターフェイスステータスTLVの表示

Junos OSは、ローカルMEPから最後に送信されたインターフェイスステータスTLVを保存します。インターフェイスステータスTLVの送信が有効になっていない場合、 show コマンドは「none」と表示されます。

次の例のように、 show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier コマンドを使用して最後に送信されたインターフェイスステータスTLV表示できます。

MACステータスの欠陥

Junos OS は、リモート MEP がポート ステータス TLV またはインターフェイス ステータス TLV で障害を報告するタイミングを示す MAC ステータス障害情報を提供します。1 つ以上のリモート MEP がインターフェイスが「アップ」ではないと報告する場合(たとえば、リモート MEP のインターフェイスが使用できない場合)、またはすべてのリモート MEP が「アップ」以外の値のポートステータス TLV を報告した場合(たとえば、すべてのリモート MEP のブリッジポートがデータを転送していない場合)、システムは「はい」と示します。2つの show コマンドを使用して、MACステータス障害表示を表示できます。

mep-databaseコマンドを使用して、MACステータス障害を表示します。

interfacesコマンドを使用して、MACステータス障害を表示します。

リモートMEPアクションプロファイルのサポートを設定する

受信したCCMパケットのinterface-status-tlvport-status-tlvの値に基づいて、action-profileオプションを使用してinterface-downなどの特定のアクションを実行できます。ルーターでは複数のアクションプロファイルを設定できますが、リモートMEPに割り当てることができるアクションプロファイルは1つだけです。

アクションプロファイルは1つ以上のイベントで設定することができ、これらのイベントのいずれかが発生するとアクションがトリガーされます。設定されているすべてのイベントが actionをトリガーする必要はありません。

アクションプロファイルは、リモートMEPレベルでのみ適用できます。

以下の例は、説明コメントを追加したアクションプロファイル設定を示しています。

リモートMEPアクションプロファイルの監視

次の例のように、 show oam ethernet connectivity-fault-management mep-database コマンドを使用すると、リモートMEPのアクションプロファイルステータスを表示できます。

show oam ethernet connectivity-fault- management mep-database remote-mep(アクションプロファイルイベント)

シャーシID TLVの設定

送信者ID TLVをパケットと一緒に送信するようにJunos OSを設定できます。送信者ID TLVは、IEEE 802.1ag規格で規定されているように、連続性チェックメッセージ(CCM)、ループバックメッセージ、およびリンクトレースメッセージ(LTM)で送信されるオプションのTLVです。送信者ID TLVには、デバイスの一意のCFMベースのMACアドレスであるシャーシIDと、IPv4またはIPv6アドレスである管理IPアドレスが含まれています。

TLVの length フィールドの値は、TLVにシャーシID情報が含まれているかどうかを示します。 length フィールドに使用可能な値は、ゼロ(0)または任意の有効な数値であり、これはそれぞれTLV内のシャーシID情報の有無を示します。

set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlvコマンドを使用することで、Junos OSが送信者ID TLVをグローバルレベルで送信できるようにすることができます。送信者ID TLVがグローバルレベルで設定されている場合、デフォルトのメンテナンスドメイン、メンテナンスアソシエーション、およびメンテナンスアソシエーション中間点(MIP)ハーフ機能がこの設定を継承します。

送信者ID TLVは、以下の階層レベルでも設定できます。

  • [edit protocols oam ethernet connectivity-fault-management]

  • [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check]

maintenance-associationレベルの送信者ID TLV設定は、グローバルレベルの設定よりも優先されます。

注:

送信者ID TLVは802.1ag PDUでのみサポートされており、パフォーマンス監視プロトコルデータユニット(PDU)ではサポートされていません。

CETモードでのMACフラッシュメッセージ処理の設定

キャリアイーサネットトランスポート(CET)モードでは、MXシリーズルーターがプロバイダエッジ(PE)ルーターとして使用され、アクセス側では標準ベースのプロトコルを実行するNokia Siemens Networks A2200キャリアイーサネットスイッチ(Eドメインデバイスと呼ばれる)が使用されます。MXシリーズルーターでは、VPLS擬似配線はラベル配布プロトコル(LDP)を通じて動的に設定されます。Eドメインデバイスでは、EドメインデバイスとMXシリーズPEルーターの間で実行される接続障害管理(CFM)セッションを通じて、トポロジーの変更が検出されます。MXシリーズPEルーターは、CFM接続が失われた場合、キャリアイーサネットインターフェイスをダウンさせることができます。これにより、ローカルMACフラッシュと、リモートMXシリーズPEに向けて送信されるターゲットラベル配布プロトコル(T-LDP)MACフラッシュ通知がトリガーされ、MACフラッシュがトリガーされます。

CET相互運用モードでは、MXシリーズルーターは、レガシープロトコルを実行するNokia Siemens Networks Ax100キャリアイーサネットアクセスデバイス(Aドメインデバイスと呼ばれる)と相互運用する必要があります。Nokia Siemens Networks A4100およびA8100デバイスは、MXシリーズPEルーターとAドメインデバイスの中間として機能します。これらの中間デバイスは、インターワーキング機能(IWF)手順を実行するため、MXシリーズルーターとAドメインデバイス間でOAM(運用管理管理)セッションを実行できます。MXシリーズPEルーターとNokia Siemens Networks A4100およびA8100中間デバイスの間にはVPLS疑似配線がないため、トポロジー変更通知を送信するためにPEルーター間で実行されているLDPプロトコルはありません。トポロジーの変更を通信するために、MXシリーズルーターはMACフラッシュをトリガーし、コアに伝送できます。MXシリーズルーターでは、接続保護タイプの長さ値(TLV)イベントに基づくアクションプロファイルを使用できます。アクションプロファイルは、MXシリーズPEルーターのキャリアエッジ 論理インターフェイス をダウンさせます。これにより、ローカルMACフラッシュがトリガーされ、LDP通知を使用してトポロジー変更がコアに伝播されます。

VPLSでは、エンドツーエンドの接続は監視されません。アクセスリングは、EドメインデバイスとMXシリーズPEルーター間、およびAドメインデバイスとMXシリーズPEルーター間(Nokia Siemens Networks A-4100デバイスがホストするIWF)の各サービスのワーキングパスおよび保護パス上で、複数のエンドポイント(MEP)でCFMを実行することで独立して監視されます。作業パスで接続障害が発生した場合、Nokia Siemens Networks Ax200デバイスは保護パスへのスイッチオーバーを実行し、トポロジー変更通知(CCMで伝送されるTLVの形式)をトリガーして、アクティブなパスに送信します。

図1:CET相互運用デュアルホームトポロジーCET inter-op Dual Homed Topology

図1 は、Aドメインに接続されたMXシリーズPEルーターのデュアルホームトポロジーを示しています。Aドメインデバイスがスイッチオーバーをトリガーすると、サービストラフィックを新しいアクティブパスにスイッチングし始めます。この変更は、ワーキングパスおよび保護パス上でそのAドメインデバイスから送信されるHELLOプロトコルデータユニット(PDU)に通知されます。A4100のIWFがこれらのHELLO PDUを受信すると、それらを標準CCMメッセージに変換し、接続保護TLVも挿入します。接続保護 TLV の "Protection-in-use" フィールドは、現在アクティブなパスでエンコードされ、CCM メッセージに含まれています。CCM メッセージは、A4100 の VLAN スポークを介して MXシリーズ PE ルーターによって受信されます。上記のデュアルホームシナリオでは、一方のMXシリーズPEルーターが作業パスを監視し、もう一方のMXシリーズPEルーターが保護パスを監視します。

MAC フラッシュは、作業パスを監視している CFM セッションがサービス トラフィックが保護パスに移動したことを検出した場合、または保護パスを監視している CFM セッションがサービス トラフィックが作業パスに移動したことを検出した場合に発生します。

図2:CET相互運用デュアル接続トポロジー CET inter-op Dual Attached Topology

図2 は、Aドメインに接続されたMXシリーズPEルーター上のデュアル接続トポロジーを示しています。この場合に使用されるMACフラッシュメカニズムも、デュアルホームシナリオのAドメインに使用されたものと同じです(図1)。ただし、この場合、両方のCFMセッションは1台のMXシリーズPEルーターによってのみホストされます。AドメインのAX100がトポロジーの変更を検出すると、MXシリーズPEルーターは、アクティブなパスを示す「Protection-in-use」の値を持つ、作業パスと保護パスのCCMメッセージで接続保護TLVを受信します。CFMセッション用に生成されたイベントに基づいて、MXシリーズPEルーターは適切なインターフェイスをダウンさせ、ローカルMACフラッシュをトリガーします。

接続保護 TLV アクションプロファイルの設定

アクションプロファイルは、受信したCCMパケットのconnection-protection-tlvの値に基づいてinterface-downアクションを実行するように設定できます。

以下の例は、説明コメントを追加したアクションプロファイル設定を示しています。

例:接続保護TLVに基づいてアクションプロファイルを設定する

この例では、CETネットワークのトポロジー変更に基づいてMACフラッシュをトリガーするために、接続保護TLVに基づいてアクションプロファイルを設定する方法を示します。

要件

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

  • Junos OSリリース11.2以降

  • MXシリーズPEルーター

概要とトポロジー

MXシリーズPEルーターを使用したCETネットワークの物理的トポロジーを 図3に示します。

トポロジー

図3:CETネットワークTopology of CET networkのトポロジー

以下の定義は、 図3で使用されるデバイスの略語と用語の意味を説明しています。

  • プロバイダエッジ(PE)デバイス—プロバイダネットワークのエッジにあるデバイスまたはデバイスのセットで、プロバイダの顧客サイトのビューを表示します。

  • Eドメイン—標準ベースのプロトコルを実行し、アクセス側で使用されるNokiaシーメンスネットワークスキャリアイーサネットスイッチ。

  • Aドメイン—レガシープロトコルを実行するNokiaシーメンスネットワークスキャリアイーサネットスイッチ。

設定

手順

ステップバイステップの手順

接続保護TLVに基づいてアクションプロファイルを設定するには、以下のタスクを実行します。

  1. アクションプロファイルを設定する

  2. 接続保護 TLV が "使用中の保護" 値 SET で受信された場合、接続保護 TLV は保護パスを使用する必要があります

  3. 接続保護 TLV が "Protection-in-use" 値の RESET で受信された場合、接続保護 TLV は作業パスを使用する必要があります

  4. インターフェイスをダウンさせるためのアクションプロファイルを設定します

結果

設定の結果を確認する

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
17.3R1
Junos OSリリース17.3R1以降、カスタマーエッジデバイスがジュニパーデバイスではない場合に、リモート障害表示(RDI)ビットを使用することで、プロバイダエッジデバイスとカスタマーエッジデバイス間の接続障害管理(CFM)監視を有効にすることができます。
16.1
リリース16.1R2以降では、送信者ID TLVをパケットと一緒に送信するようにJunos OSを設定できます。