Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

CFM-Überwachung zwischen CE- und PE-Geräten

Verwenden Sie dieses Thema, um mehr über die CFM-Überwachung zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten zu erfahren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Gerät von Juniper handelt. Außerdem können Sie mehr darüber erfahren, wie Schnittstellenstatus TLVs, Portstatus-TLVs, Gehäuse-ID TLV und Verbindungsschutz TLV bei der Überwachung Ihres Netzwerks helfen.

Asynchrone Benachrichtigung für CFM-Aktionsprofil

SUMMARY CFM-gesteuerte asynchrone Benachrichtigung ermöglicht die Verbindungsstatussynchronisierung zwischen zwei CE-Geräten, die über einen Pseudo-Draht von ihren jeweiligen PE-Geräten miteinander verbunden sind. Es emuliert das Szenario so, als wären zwei CE-Geräte direkt verbunden. CFM bietet End-to-End-Signalübertragung, auch wenn PE1 und PE2 nicht über ein einziges Netzwerk, sondern über eine Reihe von Netzwerken verbunden sind.

Layer 2-Konnektivität zwischen PE1 und PE2

Abbildung 1 ist ein Beispiel für ein Bereitstellungsszenario, in dem CFM-basierte asynchrone Benachrichtigungen zur Synchronisation des Verbindungsstatus zwischen CE1 und CE2 verwendet werden können. Die folgenden zwei Anforderungen können mit der Konfiguration einer asynchronen Benachrichtigung erfüllt werden.

  • Wenn die Verbindung zwischen PE2 und CE2 fällt, dann ist auch die Verbindung zwischen PE1 und CE1 hergestellt. Wenn die Verbindung wiederhergestellt wird, sollte sie auch den Verbindungsstatus PE1 zu CE1 wiederherstellen. Die Änderung des Verbindungsstatus zwischen PE1 und CE1 sollte ähnlich funktionieren.

  • Wenn es ein Verbindungsproblem zwischen PE1 und PE2 gibt, löst es eine Verbindung zwischen PE1 zu CE1 und PE2 zu CE2 aus. Wenn der Verbindungsstatus wiederhergestellt wird, sollte er den Verbindungsstatus an beiden Enden wiederherstellen

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,

Verständnis der CFM-Überwachung zwischen CE- und PE-Geräten

Sie können die Connectivity Fault Management (CFM)-Überwachung zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Gerät von Juniper handelt. Wenn die Schnittstelle ausfällt, gibt CFM den Status der Schnittstelle in den CC-Nachrichten weiter. Die CC-Nachricht informiert das Edge-Gerät des Kunden darüber, dass das Provider-Edge-Gerät ausfällt.

Sie können die CFM-Überwachung mit einer der beiden folgenden Optionen konfigurieren:

  • Schnittstellenstatus TLV (Typ, Länge und Wert): Sie können die Connectivity Fault Management (CFM)-Überwachung zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Gerät von Juniper handelt, indem Sie den Schnittstellenstatus TLV verwenden. Wenn die Schnittstelle ausfällt, gibt CFM den Status der Schnittstelle mithilfe des Schnittstellenstatus TLV weiter. Der Schnittstellenstatus TLV gibt den Status der Schnittstelle an, auf der der MEP, der das CCM überträgt, konfiguriert ist, oder die nächstnichte Schnittstelle im IETF RFC 2863 IF-MIB. Somit ist dem Kunden-Edge-Gerät bewusst, dass das Provider-Edge-Gerät ausfällt. Um die CFM-Überwachung mit Schnittstellenstatus-TLV zu konfigurieren, verwenden Sie die interface-status-tlv Anweisung auf Hierarchieebene [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check . Dies ist die Standardoption.

  • RDI (Remote Defect Indication) – Ab Junos OS Version 17.3R1 können Sie die Connectivity Fault Management (CFM)-Überwachung zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn das Kunden-Edge-Gerät kein Juniper-Gerät ist, indem Sie das RDI-Bit (Remote Defect Indication) verwenden. Wenn Sie die CFM-Überwachung aktivieren, übermittelt CFM den Status des Provider-Edge-Geräts über das Remote Defect Indication (RDI)-Bit in den CC-Nachrichten. Somit ist dem Kunden-Edge-Gerät bewusst, dass das Provider-Edge-Gerät ausfällt. Der RDI-Bit wird gelöscht, wenn der Service wieder eingerichtet wird. Verwenden Sie die Anweisung auf [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check Hierarchieebene, um die interface-status-send-rdi CFM-Überwachung mit dem RDI-Bit zu konfigurieren. Diese Option ist erforderlich, wenn das Edge-Gerät des Kunden den Schnittstellenstatus TLV nicht unterstützt.

Anmerkung:

Wenn die Schnittstelle auf CCC down eingestellt ist und Sie RDI konfiguriert haben, wird das RDI-Bit gesendet. CFM überwacht den Status der Schnittstelle nicht. Wenn CCC down eingestellt ist, wenn die Schnittstelle nicht im Standby ist, wird das RDI-Bit mit den CC-Nachrichten gesendet, wenn Sie RDI konfiguriert haben.

Einzelnes aktives Multihoming mit RDI-Bit

Betrachten Sie die folgende Topologie, in der es zwei Provider-Edge-Geräte (PE1 und PE2) sowie zwei Kunden-Edge-Geräte (CE1 und CE2) gibt. PE1 befindet sich im aktiven Zustand, WÄHREND SICH PE2 im Standby-Zustand befindet. CFM down MEP ist zwischen PE und CE konfiguriert. CFM erkennt, dass der CCC herunterfällt und da CFM down MEP konfiguriert ist, verfügen die generierten CC-Nachrichten über das RDI-Bit. Die CC-Nachrichten von PE2 zu CE2 haben das RDI-Bit eingestellt, um den blockierten Zustand anzuzeigen. Wenn PE2 aktiv wird, wird CCM down gelöscht und das RDI-Bit aus den nachfolgenden CC-Nachrichten gelöscht.

Aktiv/Aktiv-Multihoming - Anwendungsszenario mit RDI-Bit

Betrachten Sie die Topologie, in der es zwei Provider-Edge-Geräte (PE1 und PE2) und zwei Kunden-Edge-Geräte (CE1 und CE2) gibt. PE1 befindet sich im aktiven Zustand, WÄHREND SICH PE2 im Standby-Zustand befindet. Wenn CFM down MEP nicht zwischen PE und CE konfiguriert ist, um die Verbindungskonnektivität zu überwachen, verfügen die generierten CC-Nachrichten nicht über das RDI-Bit. CFM down MEP ist zwischen PE und CE konfiguriert. CFM erkennt, dass der CCC herunterfällt und da CFM down MEP konfiguriert ist, verfügen die generierten CC-Nachrichten über das RDI-Bit. Die CC-Nachrichten von PE2 zu CE2 haben das RDI-Bit eingestellt, um den blockierten Zustand anzuzeigen. Wenn PE2 aktiv wird, wird CCM down gelöscht und das RDI-Bit aus den nachfolgenden CC-Nachrichten gelöscht.

Konfigurieren des Portstatus TLV und Schnittstellenstatus TLV

TLVs – Übersicht

Typ, Länge und Wert (TLVs) werden im IEEE 802.1ag-Standard für CFM als Methode der Codierung variabler Länge und/oder optionaler Informationen in einer PDU beschrieben. TLVs sind nicht an bestimmten Wort- oder Oktettgrenzen ausgerichtet. TLVs folgen einander ohne Polsterung zwischen ihnen.

Tabelle 1 zeigt das TLV-Format an und gibt an, ob es erforderlich oder optional ist.

Tabelle 1: TlVs-Format

Parameter

Oktett (Sequenz)

Beschreibung

Typ

1

Erforderlich. Wenn 0, folgen keine Felder für Länge oder Wert. Wenn nicht 0, folgt mindestens das Feld Länge dem Feld Typ.

Länge

2–3

Erforderlich, wenn das Feld Typ nicht 0 ist. Nicht vorhanden, wenn das Feld Typ 0 ist. Die 16 Bits des Feldes Länge geben die Größe im Oktett des Wertfelds an. 0 im Feld Länge gibt an, dass kein Wertfeld vorhanden ist.

Wert

4

Länge, die im Feld Länge angegeben ist. Optional. Nicht vorhanden, wenn das Feld Typ 0 ist oder das Feld Länge 0 ist.

Verschiedene TLVs für CFM-PDUs

Tabelle 2 zeigt eine Reihe von TLVs, die für verschiedene CFM-PDU-Typen durch IEEE 802.1ag definiert sind. Jeder TLV kann durch den eindeutigen Wert identifiziert werden, der seinem Typfeld zugewiesen wird. Einige Feldwerte sind reserviert.

Tabelle 2: Feldwerte für verschiedene TLVs für CFM-PDUs eingeben

TLV oder Organisation

Feld eingeben

TLV beenden

0

Absender-ID TLV

1

Portstatus TLV

2

Daten-TLV

3

Schnittstellenstatus TLV

4

Antwort Eingangs-TLV

5

Antwort Egress TLV

6

LTM Egress Identifier TLV

7

LTR Egress Identifier TLV

8

Reserviert für IEEE 802.1

9 bis 30

Organisationsspezifisches TLV

31

Definiert durch ITU-T Y.1731

32 bis 63

Reserviert für IEEE 802.1

64 bis 255

Nicht jeder TLV ist für alle Arten von CFM-PDUs anwendbar.

  • Für die Continuity Check Message (CCM) gültige TLVs:

    • TLV beenden

    • Absender-ID TLV

    • Portstatus TLV

    • Schnittstellenstatus TLV

    • Organisationsspezifisches TLV

  • TLVs, die für Loopback Message (LBM) geeignet sind:

    • TLV beenden

    • Absender-ID TLV

    • Daten-TLV

    • Organisationsspezifisches TLV

  • TLVs für Loopback Reply (LBR):

    • TLV beenden

    • Absender-ID TLV

    • Daten-TLV

    • Organisationsspezifisches TLV

  • Für Linktrace Message (LTM) geltende TLVs:

    • TLV beenden

    • LTM Egress Identifier TLV

    • Absender-ID TLV

    • Organisationsspezifisches TLV

  • TLVs, die für linktrace reply (LTR) geeignet sind:

    • TLV beenden

    • LTR Egress Identifier TLV

    • Antwort Eingangs-TLV

    • Antwort Egress TLV

    • Absender-ID TLV

    • Organisationsspezifisches TLV

Die folgenden TLVs werden derzeit in den entsprechenden CFM-PDUs unterstützt:

  • TLV beenden

  • Antwort Eingangs-TLV

  • Antwort Egress TLV

  • LTR Egress Identifier TLV

  • LTM Egress Identifier TLV

  • Daten-TLV

Unterstützung für zusätzliche optionale TLVs

Folgende zusätzliche optionale TLVs werden unterstützt:

  • Portstatus TLV

  • Schnittstellenstatus TLV

Router der MX-Serie unterstützen die Konfiguration des Portstatus TLV und des Schnittstellenstatus TLV. Konfigurieren des Portstatus TLV ermöglicht es dem Betreiber, die Übertragung des Portstatus TLV in CFM-PDUs zu steuern.

Anmerkung:

Obwohl Portstatus-TLV-Konfigurationsanweisungen auf M120- und M320-Routern in der CLI sichtbar sind, kann Portstatus TLV auf diesen Systemen nicht konfiguriert werden. Portstatus TLV kann auf einer MEP-Schnittstelle nur aktiviert werden, wenn es sich um eine logische Bridge-Schnittstelle handelt, was in diesen Systemen nicht möglich ist.

Konfigurationsinformationen finden Sie in den folgenden Abschnitten:

Portstatus TLV

Der Portstatus TLV gibt die Fähigkeit des Bridge-Ports an, auf dem sich der übertragende MEP befindet, um gewöhnliche Daten zu übertragen, unabhängig vom Status des MAC. Der Wert dieses TLV wird durch die MEP-Variable enableRmepDefectgesteuert , wie in Tabelle 4dargestellt. Das Format dieses TLV ist in Tabelle 3dargestellt.

Jede Änderung des Portstatus-TLVs-Wertes löst eine zusätzliche Übertragung dieser Bridge-Ports MEP-CCMs aus.

Tabelle 3: Portstatus TLV-Format

Parameter

Oktett (Sequenz)

Typ = 2

1

Länge

2–3

Wert (siehe Tabelle 4)

4

Tabelle 4: Portstatus TLV-Werte

Mnemonische

Gewöhnliche Daten, die frei durch den Port geleitet werden

Wert

psBlocked

Nein: enableRmepDefect = falsch

1

psUp

Ja: enableRmepDefect = wahr

2

Die MEP-Variable enableRmepDefect ist eine boolesche Variable, die angibt, ob Frames auf der Serviceinstanz von den Wartungszuordnungen überwacht werden, wenn dieser MEP aktiviert ist, diesen Bridge-Port durch das Spanning Tree-Protokoll und die VLAN-Topologieverwaltung zu passieren. Sie wird auf TRUE festgelegt, wenn:

  • Der Bridge-Port ist in einem Zustand festgelegt, in dem der Datenverkehr ihn passieren kann.

  • Auf dem Bridge-Port werden mehrere Instanzen des Spanning Tree ausgeführt.

  • Die MEP-Schnittstelle ist nicht mit einer Bridging-Domäne verknüpft.

Konfigurieren des Portstatus TLV

Junos OS bietet Konfigurationsunterstützung für den Portstatus TLV, sodass Sie die Übertragung dieses TLV in CCM-PDUs steuern können. Das Junos OS stellt diese Konfiguration auf Continuity-Check-Ebene bereit. Standardmäßig enthält die CCM den Portstatus TLV nicht. Verwenden Sie die Anweisung auf [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] Hierarchieebene, um den port-status-tlv Portstatus TLV zu konfigurieren.

Anmerkung:

Portstatus TLV-Konfiguration ist nicht von IEEE 802.1ag vorgeschrieben. Das Junos OS bietet es, um dem Betreiber mehr Flexibilität zu bieten; jedoch empfängt und verarbeitet sie CCMs mit einem Portstatus TLV, unabhängig von dieser Konfiguration.

Ein Beispiel für die Konfigurationsanweisungen:

Die Portstatus-TLV-Übertragung kann in den folgenden zwei Fällen nicht aktiviert werden:

  • Wenn die MEP-Schnittstelle unter der Wartungsverkettung nicht vom Typ Bridge ist.

  • Wenn der MEP auf einer physischen Schnittstelle konfiguriert ist.

Anzeige des empfangenen Portstatus TLV

Das Junos OS speichert den zuletzt empfangenen Portstatus TLV von einem Remote-MEP. Wenn der empfangene Portstatuswert nicht einem der in Tabelle 4aufgeführten Standardwerte entspricht, zeigt der Befehl ihn show als "unbekannt" an. Sie können den zuletzt gespeicherten empfangenen Portstatus TLV wie im folgenden Beispiel mit dem show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier Befehl anzeigen:

Anzeige des Status des übertragenen Ports TLV

Das Junos OS speichert den letzten übertragenen Portstatus TLV von einem lokalen MEP. Wenn die Übertragung des Portstatus TLV nicht aktiviert ist, zeigt der show Befehl "keine" an. Sie können den zuletzt gespeicherten Übertragenen Portstatus TLV wie im folgenden Beispiel mit dem show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier Befehl anzeigen:

Schnittstellenstatus TLV

Der Schnittstellenstatus TLV gibt den Status der Schnittstelle an, auf der der MEP, der das CCM überträgt, konfiguriert ist, oder die nächstnichte Schnittstelle im IETF RFC 2863 IF-MIB. Das Format dieses TLV ist in Tabelle 5dargestellt. Die aufgezählten Werte werden in Tabelle 6dargestellt.

Tabelle 5: Schnittstellenstatus TLV-Format

Parameter

Oktett (Sequenz)

Typ = 4

1

Länge

2–3

Wert (siehe Tabelle 6)

4

Tabelle 6: Schnittstellenstatus TLV-Werte

Mnemonische

Schnittstellenstatus

Wert

isUp

oben

1

isDown

nach unten

2

isTesting

Test

3

isUnknown

Unbekannt

4

isDormant

Ruhenden

5

isNotPresent

nichtpräsentieren

6

istLowerLayerDown

lowerLayerDown

7

Anmerkung:

Wenn sich der Betriebsstatus einer logischen Schnittstelle vom Down-Status (Statuswert 2) in den unteren Layer-Down-Status (Statuswert 7) und umgekehrt ändert, wird die LinkDown SNMP-Trap nicht generiert. Wenn Sie beispielsweise ein aggregiertes Ethernet-Schnittstellenpaket mit einem VLAN-Tag konfigurieren und dem Bündel eine physische Schnittstelle hinzufügen, die sich im Betriebszustand befindet, ist der Betriebsstatus des aggregierten logischen Ethernet-Schnittstellenpakets an diesem Punkt niedriger layer down (7). Wenn Sie das mit der Schnittstelle verknüpfte MIC offline nehmen, wird der LinkDown-Trap nicht generiert, wenn sich die logische Schnittstelle vom unteren Layer-Down-Status auf den down-Status verschiebt.

In ähnlicher Weise sollten Sie ein weiteres Beispielszenario in Betracht ziehen, in dem einem aggregierten Ethernet-Bündel mit VLAN-Tagging eine physische Schnittstelle hinzugefügt wird und die aggregierte logische Ethernet-Schnittstelle deaktiviert ist. Wenn die logische Schnittstelle deaktiviert ist, ändert sich der Betriebsstatus der logischen Schnittstelle nach unten. Wenn Sie die physische Schnittstelle deaktivieren, die Teil des aggregierten Ethernet-Pakets ist, bleibt der Betriebsstatus der aggregierten logischen Ethernet-Schnittstelle unten. Wenn Sie die aggregierte logische Ethernet-Schnittstelle wieder aktivieren, ändert sich der Betriebsstatus von unten auf niedrigerer Ebene nach unten. Der LinkDown SNMP-Trap wird an diesem Punkt nicht generiert.

Konfigurieren des Schnittstellenstatus TLV

Das Junos OS bietet Konfigurationsunterstützung für den Schnittstellenstatus TLV und ermöglicht es Den Betreibern somit, die Übertragung dieses TLV in CCM-PDUs über eine Konfiguration auf der Continuity-Check-Ebene zu steuern.

Anmerkung:

Diese Konfiguration ist nicht von IEEE 802.1ag vorgeschrieben; es wird vielmehr bereitgestellt, um dem Betreiber mehr Flexibilität zu bieten. Das Junos OS empfängt und verarbeitet CCMs unabhängig von dieser Konfiguration mit dem Schnittstellenstatus TLV.

Der Schnittstellenstatus TLV-Konfiguration ist unten dargestellt:

Anmerkung:

Das Junos OS unterstützt die Übertragung von nur drei von sieben möglichen Werten für den Schnittstellenstatus TLV. Die unterstützten Werte sind 1, 2 und 7. Das Junos OS kann jedoch einen beliebigen Wert für den Schnittstellenstatus TLV erhalten.

Anzeige des empfangenen Schnittstellenstatus TLV

Das Junos OS speichert den zuletzt empfangenen Schnittstellenstatus TLV vom Remote-MEP. Wenn der empfangene Schnittstellenstatuswert nicht einem der in Tabelle 5aufgeführten Standardwerte entspricht, zeigt der show Befehl "unbekannt" an.

Sie können diesen zuletzt gespeicherten Schnittstellenstatus TLV wie im folgenden Beispiel mit dem show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier Befehl anzeigen:

Anzeige des Übertragenen Schnittstellenstatus TLV

Das Junos OS speichert den letzten übertragenen Schnittstellenstatus TLV von einem lokalen MEP. Wenn die Übertragung des Schnittstellenstatus TLV nicht aktiviert wurde, zeigt der show Befehl "none" an.

Wie im folgenden Beispiel können Sie den letzten übertragenen Schnittstellenstatus TLV mit dem show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier Befehl anzeigen:

MAC-Statusmängel

Das Junos OS liefert MAC-Statusfehlerinformationen, die darauf hinweisen, dass einer oder mehrere der Remote-MEPs in seinem Portstatus TLV oder Interface Status TLV einen Fehler melden. Es gibt "Ja" an, wenn entweder ein Remote-MEP meldet, dass seine Schnittstelle nicht isUp ist (z. B. ist mindestens eine Remote-MEPs-Schnittstelle nicht verfügbar) oder wenn alle Remote-MEPs einen Portstatus TLV melden, der einen anderen Wert als psUp enthält (z. B. alle Remote-MEPs Bridge-Ports sind keine Datenweiterleitung). Es gibt zwei show Befehle, mit denen Sie die Mac Status Defects Anzeige anzeigen können.

Verwenden Sie den mep-database Befehl, um MAC-Statusmängel anzuzeigen:

Verwenden Sie den interfaces Befehl, um MAC-Statusmängel anzuzeigen:

Konfigurieren der Remote-MEP-Aktionsprofilunterstützung

Basierend auf den Werten der interface-status-tlv und port-status-tlv in den empfangenen CCM-Paketen kann mithilfe der action-profile Optionen eine bestimmte Aktion interface-downwie ausgeführt werden. Mehrere Aktionsprofile können auf dem Router konfiguriert werden, aber einem Remote-MEP kann nur ein Aktionsprofil zugewiesen werden.

Das Aktionsprofil kann mit mindestens einem Ereignis konfiguriert werden, um die Aktion auszulösen. aber die Aktion wird ausgelöst, wenn eines dieser Ereignisse auftritt. Es ist nicht erforderlich, dass alle konfigurierten Ereignisse ausgelöst werden action.

Ein Aktionsprofil kann nur auf Der Remote-Ebene des MEP angewendet werden.

Das folgende Beispiel zeigt eine Aktionsprofilkonfiguration mit hinzugefügten Erläuternden Kommentaren:

Überwachung eines Remote-MeP-Aktionsprofils

Mit dem show oam ethernet connectivity-fault-management mep-database Befehl können Sie wie im folgenden Beispiel den Aktionsprofilstatus eines Remote-MEP anzeigen:

oam ethernet connectivity-fault-management mep-database remote-mep (Action Profile Event) anzeigen

Konfigurieren der Gehäuse-ID TLV

In Version 16.1R2 und höher können Sie Junos OS so konfigurieren, dass die Sender-ID TLV zusammen mit den Paketen gesendet wird. Die Sender-ID TLV ist ein optionaler TLV, der in Continuity Check Messages (CCMs), Loopback-Nachrichten und Link Trace Messages (LTMs) gesendet wird, wie im IEEE 802.1ag-Standard angegeben. Die Sender-ID TLV enthält die Chassis-ID, die eindeutige, CFM-basierte MAC-Adresse des Geräts, und die Management-IP-Adresse, die eine IPv4- oder IPv6-Adresse ist.

Der Wert des length Feldes in der TLV gibt an, ob der TLV die Informationen zur Gehäuse-ID enthält oder nicht. Die möglichen Werte für das length Feld sind Null (0) oder eine gültige Zahl, die das Fehlen bzw. Vorhandensein von Chassis-ID-Informationen im TLV angibt.

Sie können Junos OS aktivieren, um die Sender-ID TLV auf globaler Ebene mithilfe des Befehls set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv zu senden. Wenn die Sender-ID TLV auf globaler Ebene konfiguriert ist, übernehmen die Standard-Wartungsdomäne, die Wartungszuweisung und die Half Function Maintenance Association Intermediate Point (MIP) diese Konfiguration.

Sie können die Sender-ID TLV auch auf den folgenden Hierarchieebenen konfigurieren:

  • [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].

Die Sender-ID-TLV-Konfiguration auf Der Wartungs-Zuordnungsebene hat Vorrang vor der Konfiguration auf globaler Ebene.

Anmerkung:

Die Sender-ID TLV wird nur für 802.1ag-PDUs unterstützt und für die Leistungsüberwachung von Protokolldateneinheiten (PDUs) nicht unterstützt.

Konfigurieren der Verarbeitung von MAC-Flush Message im CET-Modus

Im Carrier-Ethernet-Transport -Modus (CET) werden Router der MX-Serie als Provider Edge (PE)-Router verwendet, und auf der Zugriffsseite werden Die Carrier-Ethernet-Switches A2200 von Nokia Siemens Networks (sogenannte E-Domain-Geräte) mit standardbasierten Protokollen verwendet. Auf den Routern der MX-Serie werden VPLS-Pseudowires dynamisch über das Label Distribution Protocol (LDP) konfiguriert. Auf E-Domain-Geräten werden Topologieänderungen durch CfM-Sitzungen (Connectivity Fault Management) erkannt, die zwischen den E-Domain-Geräten und den PE-Routern der MX-Serie ausgeführt werden. Die PE-Router der MX-Serie können die Carrier-Ethernet-Schnittstelle herunterholen, wenn CFM-Konnektivitätsverluste auftreten. Dies löst eine lokale MAC-Spülung sowie eine gezielte Label Distribution Protocol (T-LDP) MAC-Flush-Benachrichtigung aus, die an die Remote-PEs der MX-Serie gesendet wird, um einen MAC-Flush auf ihnen auszulösen.

Im MEZ-Inter-Op-Modus müssen Router der MX-Serie mit den Ax100 Carrier Ethernet-Zugriffsgeräten von Nokia Siemens Networks (sogenannte A-Domain-Geräte) zusammenarbeiten, auf denen ältere Protokolle ausgeführt werden. Die Geräte A4100 und A8100 von Nokia Siemens Networks fungieren als Zwischenprodukt zwischen den PE-Routern der MX-Serie und den Geräten der A-Domäne. Diese Zwischengeräte führen Iwf-Verfahren (Interworking Function) aus, sodass Operations Administration Management (OAM)-Sitzungen zwischen Routern der MX-Serie und Geräten mit einer Domäne ausgeführt werden können. Zwischen den PE-Routern der MX-Serie und den Geräten A4100 und A8100 von Nokia Siemens Networks gibt es keine VPLS-Pseudowires. Zwischen den PE-Routern wird also kein LDP-Protokoll ausgeführt, um Änderungen an die Topologie zu senden. Um Topologieänderungen zu kommunizieren, können Router der MX-Serie einen MAC-Flush auslösen und ihn im Core verbreiten. Router der MX-Serie können Aktionsprofile basierend auf dem Connection Protection Type Length Value (TLV)-Ereignis verwenden. Das Aktionsprofil senkt die logische Carrier-Edge-Schnittstelle in PE-Routern der MX-Serie, die einen lokalen MAC-Flush auslösen und die Topologieänderung mithilfe von LDP-Benachrichtigungen an den Core weitergeben.

Für VPLS wird keine End-to-End-Konnektivität überwacht. Die Zugangsringe werden unabhängig überwacht, indem CFM auf den Arbeits- und Schutzpfaden für jeden der Dienste zwischen den E-Domain-Geräten und den PE-Routern der MX-Serie und zwischen den A-Domain-Geräten und den PE-Routern der MX-Serie ausgeführt wird, die von den Nokia Siemens Networks A-4100-Geräten gehostet werden. Bei einem Verbindungsfehler auf dem Arbeitspfad führen die Ax200-Geräte von Nokia Siemens Networks eine Umstellung auf den Schutzpfad durch, wodurch eine Topologieänderungsbenachrichtigung (in Form von in CCM übertragenen TLVs) ausgelöst wird, die auf dem aktiven Pfad gesendet wird.

Abbildung 1: CET inter-op Dual Homed TopologyCET inter-op Dual Homed Topology

Abbildung 1 beschreibt die Dual-Homed-Topologie auf mit der A-Domain verbundenen PE-Routern der MX-Serie. Wenn ein A-Domain-Gerät einen Switchover auslöst, wird der Servicedatenverkehr auf den neuen aktiven Pfad umgestellt. Diese Änderung wird in den HELLO Protocol Data Units (PDUs) kommuniziert, die von diesem A-Domain-Gerät auf den Arbeits- und Schutzpfaden gesendet werden. Wenn der IWF in A4100 diese HELLO-PDUs wieder aufträgt, konvertiert er sie in Standard-CCM-Nachrichten und fügt auch einen Verbindungsschutz TLV ein. Das Feld "Protection-in-Use" des Verbindungsschutzes TLV ist mit dem aktuell aktiven Pfad codiert und in der CCM-Nachricht enthalten. CCM-Nachrichten werden von den PE-Routern der MX-Serie über den VLAN-Spoke in A4100 empfangen. Im obigen Dual-Homed-Szenario überwacht ein PE-Router der MX-Serie den Arbeitspfad und der andere PE-Router der MX-Serie den Schutzpfad.

Ein MAC-Flush tritt auf, wenn die CFM-Sitzung, die den funktionierenden Pfad überwacht, erkennt, dass der Servicedatenverkehr auf den Schutzpfad verschoben wurde, oder wenn die CFM-Sitzung, die den Schutzpfad überwacht, erkennt, dass der Servicedatenverkehr auf den Arbeitspfad verschoben wurde.

Abbildung 2: CET inter-op Dual Attached TopologyCET inter-op Dual Attached Topology

Abbildung 2 beschreibt die mit der A-Domain verbundene Dual-Attached-Topologie auf PE-Routern der MX-Serie. Der in diesem Fall verwendete MAC-Spülmechanismus ist auch der gleiche wie der für die A-Domain im Dual-Homed-Szenario (Abbildung 1). In diesem Fall werden beide CFM-Sitzungen jedoch von nur einem PE-Router der MX-Serie gehostet. Wenn Ax100 in der A-Domäne Topologieänderungen erkennt, empfängt der PE-Router der MX-Serie den Verbindungsschutz TLV in der CCM-Nachricht für die Arbeits- und Schutzpfade mit dem Wert "Protection-in-use", der angibt, welcher Pfad aktiv ist. Basierend auf dem Ereignis, das für die CFM-Sitzung generiert wird, bringt der PE-Router der MX-Serie die entsprechende Schnittstelle herunter, die einen lokalen MAC-Flush auslöst.

Konfigurieren eines Verbindungsschutzes TLV-Aktionsprofil

Ein Aktionsprofil kann so konfiguriert werden, dass die interface-down Aktion basierend auf den Werten der connection-protection-tlv empfangenen CCM-Pakete ausgeführt wird.

Das folgende Beispiel zeigt eine Aktionsprofilkonfiguration mit hinzugefügten Erläuternden Kommentaren:

Beispiel: Konfigurieren eines Aktionsprofils basierend auf Verbindungsschutz-TLVs

In diesem Beispiel wird gezeigt, wie sie ein Aktionsprofil basierend auf dem Verbindungsschutz-TLV konfigurieren, um MAC-Spülungen basierend auf Topologieänderungen in einem CET-Netzwerk auszulösen.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Junos OS Version 11.2 oder höher

  • Ein PE-Router der MX-Serie

Überblick und Topologie

Die physische Topologie eines CET-Netzwerks mit PE-Routern der MX-Serie wird in Abbildung 3

Topologie

Abbildung 3: Topologie des CET-NetzwerksTopologie des CET-Netzwerks

Die folgenden Definitionen beschreiben die Bedeutung der Gerätekürzel und begriffe, die in Abbildung 3verwendet werden.

  • Provider-Edge-Gerät (PE) – Ein Gerät oder eine Gruppe von Geräten am Edge des Provider-Netzwerks, das die Sicht des Anbieters auf den Kundenstandort darstellt.

  • E-Domain: Die Carrier-Ethernet-Switches von Nokia Siemens Networks nutzen standardbasierte Protokolle und werden auf der Zugriffsseite verwendet.

  • A-Domäne – Carrier-Ethernet-Switches von Nokia Siemens Networks, die auf älteren Protokollen ausgeführt werden.

Konfiguration

Verfahren

Schritt-für-Schritt-Verfahren

Um ein Aktionsprofil basierend auf dem Verbindungsschutz-TLV zu konfigurieren, erstellen Sie folgende Aufgaben:

  1. Konfigurieren eines Aktionsprofils

  2. Wenn der Verbindungsschutz TLV mit einem "Protection-in-Use"-Wert von SET empfangen wird, sollte der Verbindungsschutz TLV den Schutzpfad verwenden

  3. Wenn der Verbindungsschutz TLV mit einem "Protection-in-Use"-Wert von RESET empfangen wird, sollte der Verbindungsschutz TLV den Arbeitspfad verwenden

  4. Konfigurieren Sie das Aktionsprofil, um die Schnittstelle zum Erliegen zu bringen

Ergebnisse

Überprüfen Sie die Ergebnisse der Konfiguration

Release-Verlaufstabelle
Release
Beschreibung
17.3R1
Ab Junos OS Version 17.3R1 können Sie die Connectivity Fault Management (CFM)-Überwachung zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Gerät von Juniper handelt, indem Sie das RDI-Bit (Remote Defect Indication) verwenden.
16.1
In Version 16.1R2 und höher können Sie Junos OS so konfigurieren, dass die Sender-ID TLV zusammen mit den Paketen gesendet wird.