Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

このトピックでは、顧客のエッジデバイスが Juniper デバイスではない場合に、プロバイダエッジデバイスと顧客エッジデバイス間の CFM 監視の詳細について説明します。また、ネットワークの監視に役立つインターフェイスステータス tlvs ポートステータス tlvs、シャーシ ID TLV、および接続保護 TLV の詳細についても理解できます。

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

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

PE1 と PE2 の間のレイヤー 2 接続

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

  • PE2 から CE2 へのリンクがダウンすると、PE1 から CE1 へのリンクもダウンします。リンクが復元された後、リンク ステータス PE1 も CE1 に復元する必要があります。PE1 から CE1 へのリンク ステータスの変更も同様の方法で行う必要があります。

  • PE1 から PE2 への接続に問題が発生すると、PE1 から CE1 と PE2 から CE2 へのリンクがトリガーされます。接続ステータスが復元された場合、両端のリンク ステータスを復元する必要があります。

Configuring a CFM Action Profile to Asyncronus Notification

SUMMARY CFM UP-MEP on PE1 to PE2, monitors the connectivity between PE1 to PE2. Use of interface-status-tlv on these UP-MEP end points conveys the link status between PE1 to CE1 to PE2 and link-status between PE2 to CE2 to PE1. Action profile must be configured on PE1 to PE2 to drive asynchronous-notification towards respective CE devices . It is triggered when either adjacency-loss is detected or link-down is detected in the received interface-status-tlv.

  1. Enable asynchronous-notification at interface level

    For example

  2. Configure the action profile and the CFM event(s) to triggered this action profile at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. You can configure more than one event in the action profile

    For example

    The action asynchronous-notification is not supported with events other than interface-status-tlv down, interface-status-tlv lower-layer-down and adjacency-loss. Any other events configured results in a commit error

    .
  3. Define the action to asynchronous-notification at the [edit protocols oam ethernet connectivity-fault-management action-profile profile-name] hierarchy level.
  4. Define the maintenance domain at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level and specify the maintenance-association parameters

    For example

  5. Configure the generation of interface-status-tlv .it is required if asynchronous-notification configured based on interface-status-tlv.

    For example

  6. Define the maintenance association endpoint at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level and specify the associated parameters.

    For example

  7. Set asynchronous-notification action profile at the RMEP level.

    For example,

CE と PE デバイス間の CFM 監視について

顧客のエッジデバイスが Juniper デバイスではない場合に、プロバイダエッジデバイスと顧客エッジデバイス間での接続障害管理 (CFM) の監視を有効にすることができます。インターフェイスがダウンすると、CFM は CC メッセージにインターフェイスのステータスを反映します。CC メッセージから、顧客エッジデバイスに対して、プロバイダエッジデバイスがダウンしていることが通知されます。

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

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

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

注:

インターフェースが CCC ダウンに設定されていて、RDI が構成されている場合、RDI ビットが送信されます。CFM は、インターフェイスのステータスを監視しません。インターフェイスがスタンバイでないときに CCC を設定した場合、rdi を設定すると、RDI ビットが CC メッセージとともに送信されます。

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

2つのプロバイダエッジデバイス (PE1 および PE2) と2つの顧客エッジデバイス (CE1 および CE2) がある場合は、次のトポロジについて検討します。PE1 は、PE2 がスタンバイ状態になっているときにアクティブ状態になっています。CFM down MEP は、PE と CE の間に設定されています。CFM は、CCC がダウンし、CFM down MEP が設定されていることを検知し、生成される CC メッセージに RDI ビットを設定しています。PE2 から CE2 への CC メッセージは、ブロックされた状態を示すために RDI ビットが設定されています。PE2 がアクティブになると、CCM down がクリアされ、その後の CC メッセージから RDI ビットが消去されます。

アクティブ/アクティブマルチホーミング使用事例 RDI ビットを使用

2つのプロバイダエッジデバイス (PE1 および PE2) と2つの顧客エッジデバイス (CE1 と CE2) があるトポロジを考えてみましょう。PE1 は、PE2 がスタンバイ状態になっているときにアクティブ状態になっています。CFM down MEP が PE と CE の間でリンク接続を監視するように設定されていない場合、生成される CC メッセージには RDI ビットはありません。CFM down MEP は、PE と CE の間に設定されています。CFM は、CCC がダウンし、CFM down MEP が設定されていることを検知し、生成される CC メッセージに RDI ビットを設定しています。PE2 から CE2 への CC メッセージは、ブロックされた状態を示すために RDI ビットが設定されています。PE2 がアクティブになると、CCM down がクリアされ、その後の CC メッセージから RDI ビットが消去されます。

ポートステータス TLV とインターフェイスステータスの TLV を構成する

TLVs 概要

型、長さ、値 (TLVs) は、PDU の可変長およびオプションの情報をエンコードする方法として、CFM の IEEE 802.1 ag 規格で説明されています。TLVs が特定の単語またはオクテット境界に整列されていません。「TLVs は、それぞれの間にパディングを使用せずに詰めます。

表 1TLV 形式を表示し、必須またはオプションのどちらであるかを示します。

表 1: TLVs の形式

パラメーター

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

説明

種類

1

必須。0の場合、長さまたは値フィールドはその後に続きます。0以外の場合は、少なくとも [長さ] フィールドは [タイプ] フィールドの後に続きます。

期間

2–3

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

金額

4

長さフィールドで指定された長さ。ナ. Type フィールドが0の場合、または長さフィールドが0の場合は表示されません。

CFM Pdu の各種 TLVs の比較

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

表 2: さまざまな TLVs CFM Pdu のフィールド値を入力

TLV または組織

タイプフィールド

エンド TLV

0

Sender 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

Y.1731 によって定義されています。

32 ~ 63

IEEE 802.1 用に予約

64 ~ 255

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

  • TLVs 適用可能なビジネス継続性チェックメッセージ (CCM):

    • エンド TLV

    • Sender ID TLV

    • ポートのステータス TLV

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

    • 組織固有の TLV

  • TLVs (ループバックメッセージに適用) (LBM):

    • エンド TLV

    • Sender ID TLV

    • データ TLV

    • 組織固有の TLV

  • TLVs ループバック応答への適用 (LBR):

    • エンド TLV

    • Sender ID TLV

    • データ TLV

    • 組織固有の TLV

  • TLVs のリンクトレースメッセージ (LTM) の場合:

    • エンド TLV

    • LTM 送信識別子 TLV

    • Sender ID TLV

    • 組織固有の TLV

  • TLVs リンクトレース応答 (LTR) の比較 (& a):

    • エンド TLV

    • LTR 出口識別子 TLV

    • 応答入口 TLV

    • 応答送信 TLV

    • Sender ID TLV

    • 組織固有の TLV

次の TLVs は、該当する CFM Pdu で現在サポートされています。

  • エンド TLV

  • 応答入口 TLV

  • 応答送信 TLV

  • LTR 出口識別子 TLV

  • LTM 送信識別子 TLV

  • データ TLV

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

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

  • ポートのステータス TLV

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

MX シリーズルーターは、ポートステータス TLV とインターフェイスステータス TLV の構成をサポートします。ポートステータス TLV を設定することで、CFM Pdu のポートステータス TLV の伝送を制御できます。

注:

ポートステータス TLV の構成ステートメントは CLI では M120 および M320 ルーターに表示されますが、これらのシステムではポートステータスの TLV を構成することはできません。Port Status TLV は、このようなシステム上ではできないブリッジ論理インタフェースである場合にのみ、MEP インターフェイスで有効にすることができます。

構成情報については、以下のセクションを参照してください。

ポートのステータス TLV

ポートステータス TLV は、MAC のステータスに関係なく、伝送用の p が常駐するブリッジポートの機能を示します。これにより、通常のデータが渡されます。この TLV の価値は、にenableRmepDefect表 4示すように、mep 変数によって決定されます。この TLV の形式は、に表 3示しています。

ポートステータス TLVs value を変更すると、そのブリッジポートの1回分の送信がトリガーされます。

表 3: ポートステータス TLV 形式

パラメーター

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

タイプ = 2

1

期間

2–3

価値 (を表 4参照)

4

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

アクセラレータ

通常のデータがポートを介して自由に受け渡し

金額

psBlocked

違います:enableRmepDefect= false

1

psUp

うん:enableRmepDefect= true

2

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

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

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

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

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

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

注:

Port Status TLV configuration は、802.1 ag によって義務付けられ IEEE ているわけではありません。Junos OS では、より柔軟に運用事業を提供できるようにしています。しかし、この設定に関係なく、CCMs をポートステータス TLV で受信して処理します。

構成ステートメントの例は次のとおりです。

以下の2つのケースでは、ポートステータス TLV 伝送を有効にすることはできません。

  • 保守関連の下の MEP インターフェイスがブリッジ型でない場合

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

受信したポート状態 TLV の表示

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

送信ポートステータス TLV を表示する

Junos OS は、最後に送信されたポートのステータス TLV をローカルの MEP から保存します。ポートステータス 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 が設定されているインタフェースのステータスを示します。また、MIB の場合、IETF RFC 2863 の次の下位インターフェースになります。この TLV の形式は、に表 5示しています。列挙値はに表 6示されています。

表 5: インターフェイスステータス TLV 形式

パラメーター

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

タイプ = 4

1

期間

2–3

価値 (を表 6参照)

4

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

アクセラレータ

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

金額

isUp

する

1

isDown

ロック

2

isTesting

3

isUnknown

です

4

isDormant

快適

5

isNotPresent

notPresent

6

レイヤーダウン

最小レイヤーダウン

7

注:

論理インタフェースの動作ステータスがダウン状態 (ステータス値 2) から下位レイヤーダウン状態 (ステータス値 7) に変化すると、リンクダウン SNMP トラップが生成されない場合があります。たとえば、VLAN タグ付きのアグリゲートイーサネットインターフェイスバンドルを構成し、運用停止状態にある物理インタフェースをバンドルに追加した場合、そのポイントにおけるアグリゲートイーサネット論理インタフェースバンドルの動作ステータスは低くなります。レイヤー下 (7) インターフェイスに関連付けられている MIC をオフラインにすると、論理インタフェースが下位レイヤーダウン状態からダウン状態に変化しても、リンクダウントラップが生成されません。

同様に、VLAN タグを持つアグリゲート型イーサネットバンドルに物理インタフェースが追加されていて、アグリゲートイーサネット論理インタフェースが無効になっている別のサンプルシナリオも検討してください。論理インタフェースが無効になっている場合、論理インタフェースの動作ステータスは [停止] に変わります。アグリゲート型イーサネットバンドルの一部である物理インタフェースを無効にすると、アグリゲート型イーサネット論理インタフェースの運用ステータスはダウンしたままになります。アグリゲート型イーサネット論理インタフェースを再び有効にすると、そのインターフェイスの動作ステータスは下から下位レイヤーへと変化します。この時点では、LinkDown SNMP トラップは生成されません。

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

Junos OS は、インターフェイスステータス TLV の構成をサポートします。これにより、事業者は、連続性チェックレベルの設定を通じて、CCM Pdu のこの TLV の伝送を制御できるようになります。

注:

この設定は IEEE 802.1 ag では必須ではありません。また、より柔軟に運用事業を提供できるようになります。Junos OS は、この設定に関係なく、CCMs をインターフェイスステータス TLV で受け取り、処理します。

インターフェイスステータス TLV の構成を以下に示します。

注:

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

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

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

この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 を表示できます。

MAC ステータス障害

Junos OS は、MAC ステータス不良情報を提供します。これは、1つまたは複数のリモート MEPs が、ポートステータス TLV またはインターフェイスステータス TLV で障害を報告していることを示しています。一部のリモート MEP が、そのインターフェイスがUp(少なくとも 1 つのリモート MEP インターフェイスが使用できないなど)ことを報告している場合、またはすべてのリモート MEP が、psUp 以外の値を含むポート ステータス TLV を報告している場合(たとえば、すべてのリモート MEP ブリッジ ポートが転送データを転送していないなど)場合は、「はい」と表示されます。MAC ステータス障害showを表示するために使用できるコマンドが2つあります。

MAC 状態mep-databaseの障害を表示するには、以下のコマンドを使用します。

MAC 状態interfacesの障害を表示するには、以下のコマンドを使用します。

リモート MEP アクションプロファイルサポートの構成

またinterface-status-tlvport-status-tlv 、受信された CCM パケットの値に基づいて、などの特定interface-downのアクションをaction-profileオプションを使用して実行することができます。ルーター上で複数のアクションプロファイルを設定できますが、リモート 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(Action Profile Event)

シャーシ ID TLV の構成

リリース 16.1 R2 以降では、パケットとともに sender ID TLV を送信するように Junos OS を設定できます。Sender ID TLV は、IEEE 802.1 ag 標準で指定された、TLV の連続性チェックメッセージ (CCMs)、ループバックメッセージ、およびリンクトレースメッセージ (LTMs) で送信される省略可能なオプションです。Sender ID TLV には、デバイスの一意の CFM ベースの MAC アドレスであるシャーシ ID と、IPv4 または IPv6 アドレスである管理 IP アドレスが含まれています。

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

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

また、以下の階層レベルで sender 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]

メンテナンス関連レベルでの sender ID TLV の設定は、グローバルレベルの構成よりも優先されます。

注:

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

ヨーロッパモードでの MAC フラッシュメッセージ処理の構成

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

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

VPLS では、エンドツーエンドの接続は監視されていません。アクセスリングを個別に監視するには、電子ドメインデバイスと MX シリーズ PE ルーター間、および A ドメインデバイスと MX シリーズ PE 間の各サービスについて、それぞれの稼働および保護のパスで複数のエンドポイント (MEPs) を実行します。ルーターは、Nokia Siemens Networks A-4100 デバイスによってホストされている IWF です。ワーキングパスに接続障害が発生した場合、Nokia Siemens Networks Ax200 デバイスは、アクティブパスで送信されるトポロジー変更通知 (TLVs 繰り越さ形式) をトリガーして、保護パスへのスイッチオーバーを実行します。

図 1: 中央から 2-op デュアルホームトポロジ中央から 2-op デュアルホームトポロジ

図 1A ドメインに接続された MX シリーズ PE ルーター上のデュアルホームトポロジについて説明します。A ドメインデバイスがスイッチオーバーをトリガーすると、サービストラフィックの新しいアクティブパスへの切り替えが開始されます。この変更は、そのドメインデバイスのワーキングおよび protection パス上で送信される HELLO プロトコルデータユニット (Pdu) で伝達されます。A4100 の IWF がこれらの recieves の Pdu を標準の CCM メッセージに変換し、接続保護 TLV も挿入します。接続保護の「Protection-in-use」フィールドは、現在アクティブなパスでエンコードされ、CCM メッセージに含まれています。CCM メッセージは、A4100 の VLAN スポークを通じて MX シリーズ PE ルーターによって受信されます。上記のデュアルホームのシナリオでは、1つの MX シリーズ PE ルーターが動作するパスを監視し、その他の MX シリーズ pe ルーターが保護パスを監視します。

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

図 2: 中央にある-op デュアルアタッチ型トポロジー中央にある-op デュアルアタッチ型トポロジー

図 2A ドメインに接続された MX シリーズ PE ルーターのデュアル接続トポロジについて説明します。この場合に使用される MAC フラッシュメカニズムは、デュアルホームシナリオの A ドメインで使用されるものと同じでもあります (図 1)。ただし、この場合、CFM セッションは、1つの MX シリーズ PE ルーターでのみホストされます。A ドメインの Ax100 がトポロジーの変更を検出すると、MX シリーズ PE ルーターは、アクティブなパスを示す「プロテクションインユーザー保護」の値を使用して、ワーキング パスと保護パスに関する CCM メッセージで接続保護 TLV を受信します。CFM セッション用に生成されたイベントに基づいて、MX シリーズ PE ルーターは、ローカル MAC のフラッシュをトリガーする適切なインターフェイスをダウンします。

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

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

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

例:接続保護-TLVs をベースとしたアクションプロファイルの設定

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

要件

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

  • Junos OS リリース11.2 以降

  • MX シリーズ PE ルーター

概要とトポロジー

MX シリーズ PE ルーターを使用した中央ネットワークの物理トポロジは以下のとおりです。図 3

Topology

図 3: 中央ネットワークのトポロジ中央ネットワークのトポロジ

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

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

  • E-Domain:Nokia Siemens Networks Carrier イーサネット スイッチ標準ベースのプロトコルを実行し、アクセス側で使用されています。

  • A-Domain:Nokia Siemens Networks Carrier イーサネット スイッチ プロトコルを実行するサービスを提供。

構成

手順

順を追った手順

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

  1. アクションプロファイルの設定

  2. 接続保護 TLV が SET の「プロテクションイン使用」値で受信された場合、接続保護 TLV は保護パスを使用する必要があります。

  3. 接続保護 TLV が RESET の「保護イン使用」値で受信された場合、接続保護 TLV はワーキング パスを使用する必要があります。

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

結果

構成の結果を確認します。

リリース履歴テーブル
リリース
説明
17.3R1
Junos OS リリース 17.3 R1 では、リモート欠陥表示 (RDI) ビットを使用して、顧客のエッジデバイスが Juniper デバイスでない場合に、プロバイダエッジデバイスと顧客エッジデバイス間の接続障害管理 (CFM) 監視を有効にできます。
16.1
リリース 16.1 R2 以降では、パケットとともに sender ID TLV を送信するように Junos OS を設定できます。