CFM-Überwachung zwischen CE- und PE-Geräten
In diesem Thema erfahren Sie mehr über die CFM-Überwachung zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Juniper-Gerät handelt. Außerdem erfahren Sie mehr darüber, wie Schnittstellenstatus-TLVs, Portstatus-TLVs, Chassis-ID-TLV und Verbindungsschutz-TLV bei der Überwachung Ihres Netzwerks helfen.
Asynchrone Benachrichtigung über CFM-Aktionsprofile
SUMMARY CFM-gesteuerte asynchrone Benachrichtigung ermöglicht die Synchronisierung des Verbindungsstatus zwischen zwei CE-Geräten, die über einen Pseudodraht miteinander verbunden sind, der von ihren jeweiligen PE-Geräten ausgeht. Es ahmt das Szenario so dar, als ob zwei CE-Gerätedirekt miteinander verbunden wären. CFM bietet End-to-End-Signalübertragung auch dann, 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 zeigt ein Beispiel für ein Bereitstellungsszenario, in dem CFM-basierte asynchrone Benachrichtigungen verwendet werden können, um den Verbindungsstatus zwischen CE1 und CE2 zu synchronisieren. Die folgenden zwei Voraussetzungen können mit der Konfiguration von asynchronous-notification erfüllt werden.
-
Wenn die Verbindung zwischen PE2 und CE2 unterbrochen wird, wird auch die Verbindung zwischen PE1 und CE1 unterbrochen. Wenn die Verbindung wiederhergestellt ist, sollte auch der Verbindungsstatus PE1 auf CE1 zurückgesetzt werden. Die Änderung des Verbindungsstatus zwischen PE1 und CE1 sollte auf ähnliche Weise funktionieren.
-
Wenn ein Verbindungsproblem zwischen PE1 und PE2 auftritt, wird eine Verbindung zwischen PE1 und CE1 und PE2 zu CE2 ausgelöst. Wenn der Verbindungsstatus wiederhergestellt wird, sollte der Verbindungsstatus an beiden Enden wiederhergestellt werden
Siehe auch
Konfigurieren eines CFM-Aktionsprofils für Asyncronus-Benachrichtigungen
SUMMARY CFM UP-MEP auf PE1 bis PE2 überwacht die Konnektivität zwischen PE1 und PE2. Die Verwendung von auf diesen UP-MEP-Endpunkten übermittelt den Verbindungsstatus zwischen PE1 und CE1 bis PE2 und den Verbindungsstatus zwischen PE2 und CE2 bis PE1.interface-status-tlv Das Aktionsprofil muss auf PE1 bis PE2 konfiguriert werden, um asynchrone Benachrichtigungen an die entsprechenden CE-Geräte zu steuern. Es wird ausgelöst, wenn entweder ein Adjacency-Verlust oder ein Link-Down in der empfangenen .interface-status-tlv
Siehe auch
Grundlegendes zur CFM-Überwachung zwischen CE- und PE-Geräten
Sie können die Überwachung des Konnektivitätsfehlermanagements (Connectivity Fault Management, CFM) zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Juniper-Gerät handelt. Wenn die Schnittstelle ausgefallen ist, gibt CFM den Status der Schnittstelle in den CC-Nachrichten weiter. Die CC-Meldung informiert das Edge-Gerät des Kunden darüber, dass das Edge-Gerät des Anbieters ausgefallen ist.
Sie können die CFM-Überwachung mit einer der beiden folgenden Optionen konfigurieren:
Schnittstellenstatus-TLV (Typ, Länge und Wert): Mithilfe von Schnittstellenstatus-TLV können Sie die Überwachung des Konnektivitätsfehlermanagements (CFM) zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Juniper-Gerät handelt. Wenn die Schnittstelle ausgefallen ist, gibt CFM den Status der Schnittstelle mithilfe von Schnittstellenstatus-TLV weiter. Der Schnittstellenstatus-TLV gibt den Status der Schnittstelle an, auf der der MEP, der das CCM überträgt, konfiguriert ist, oder der nächstniedrigeren Schnittstelle im IETF RFC 2863 IF-MIB. Somit weiß das Edge-Gerät des Kunden, dass das Edge-Gerät des Anbieters ausgefallen ist. Um die CFM-Überwachung mit Interface Status TLV zu konfigurieren, verwenden Sie die Anweisung auf Hierarchieebene .
interface-status-tlv[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkDies ist die Standardoption.RDI (Remote Defect Indication) – Ab Junos OS Version 17.3R1 können Sie die Überwachung des Konnektivitätsfehlermanagements (Connectivity Fault Management, CFM) zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn es sich bei dem Kunden-Edge-Gerät nicht um ein Juniper-Gerät handelt, indem Sie das Remote Defect Indication (RDI)-Bit verwenden. Wenn Sie die CFM-Überwachung aktivieren, gibt CFM den Status des Provider-Edge-Geräts über das RDI-Bit (Remote Defect Indication) in den CC-Nachrichten weiter. Somit weiß das Edge-Gerät des Kunden, dass das Edge-Gerät des Anbieters ausgefallen ist. Das RDI-Bit wird gelöscht, wenn der Dienst gesichert ist. Um die CFM-Überwachung mit dem RDI-Bit zu konfigurieren, verwenden Sie die Anweisung auf Hierarchieebene .
interface-status-send-rdi[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkDiese Option ist erforderlich, wenn das Kunden-Edge-Gerät die Schnittstellenstatus-TLV nicht unterstützt.
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, während die Schnittstelle nicht im Standby-Modus ist, wird das RDI-Bit mit den CC-Nachrichten gesendet, wenn Sie RDI konfiguriert haben.
- Einzelner aktiver Multi-Homing-Anwendungsfall mit RDI-Bit
- Aktiv/Aktiv-Multihoming Anwendungsfall mit RDI-Bit
Einzelner aktiver Multi-Homing-Anwendungsfall mit RDI-Bit
Stellen Sie sich die folgende Topologie vor, in der zwei Anbieter-Edge-Geräte (PE1 und PE2) sowie zwei Kunden-Edge-Geräte (CE1 und CE2) vorhanden sind. PE1 befindet sich im aktiven Zustand, während sich PE2 im Standby-Zustand befindet. CFM down MEP wird zwischen PE und CE konfiguriert. CFM erkennt, dass der CCC ausfällt, und da CFM down-MEP konfiguriert ist, haben die generierten CC-Nachrichten das RDI-Bit. In den CC-Nachrichten von PE2 bis CE2 ist das RDI-Bit so eingestellt, dass es den blockierten Zustand anzeigt. Wenn PE2 aktiv wird, wird CCM down gelöscht und das RDI-Bit wird aus den nachfolgenden CC-Nachrichten gelöscht.
Aktiv/Aktiv-Multihoming Anwendungsfall mit RDI-Bit
Betrachten Sie die Topologie mit zwei Anbieter-Edge-Geräten (PE1 und PE2) und zwei Kunden-Edge-Geräten (CE1 und CE2). PE1 befindet sich im aktiven Zustand, während sich PE2 im Standby-Zustand befindet. Wenn CFM down MEP zwischen PE und CE nicht konfiguriert ist, um die Verbindungskonnektivität zu überwachen, verfügen die generierten CC-Nachrichten nicht über das RDI-Bit. CFM down MEP wird zwischen PE und CE konfiguriert. CFM erkennt, dass der CCC ausfällt, und da CFM down-MEP konfiguriert ist, haben die generierten CC-Nachrichten das RDI-Bit. In den CC-Nachrichten von PE2 bis CE2 ist das RDI-Bit so eingestellt, dass es den blockierten Zustand anzeigt. Wenn PE2 aktiv wird, wird CCM down gelöscht und das RDI-Bit wird aus den nachfolgenden CC-Nachrichten gelöscht.
Siehe auch
Konfigurieren von Portstatus-TLV und Schnittstellenstatus-TLV
- TLVs im Überblick
- Verschiedene TLVs für CFM-PDUs
- Unterstützung für zusätzliche optionale TLVs
- MAC-Status-Defekte
- Konfigurieren der Unterstützung von Remote-MEP-Aktionsprofilen
- Überwachen eines Remote-MEP-Aktionsprofils
TLVs im Überblick
Typ, Länge und Wert (TLVs) werden im IEEE 802.1ag-Standard für CFM als Methode zur Codierung von Informationen variabler Länge und/oder optionaler Informationen in einer PDU beschrieben. TLVs sind nicht an einer bestimmten Wort- oder Oktettgrenze ausgerichtet. TLVs folgen einander ohne Polsterung dazwischen.
Tabelle 1 zeigt das TLV-Format an und gibt an, ob es erforderlich oder optional ist.
Parameter |
Oktett (Sequenz) |
Beschreibung |
|---|---|---|
Typ |
1 |
Erforderlich. Bei 0 folgen keine Längen- oder Wertfelder. Wenn nicht 0, folgt mindestens das Feld "Länge" auf das Feld "Typ". |
Länge |
2–3 |
Erforderlich, wenn das Feld Typ nicht 0 ist. Nicht vorhanden, wenn das Feld Typ den Wert 0 hat. Die 16 Bit des Felds Länge geben die Größe des Felds Wert in Oktetten an. 0 im Feld Länge gibt an, dass kein Wertfeld vorhanden ist. |
Wert |
4 |
Länge, die durch das Feld Länge angegeben wird. Optional. Nicht vorhanden, wenn das Feld "Type" den Wert 0 oder das Feld "Length" den Wert 0 hat. |
Verschiedene TLVs für CFM-PDUs
Tabelle 2 zeigt eine Reihe von TLVs, die durch IEEE 802.1ag für verschiedene CFM-PDU-Typen definiert sind. Jede TLV kann durch den eindeutigen Wert identifiziert werden, der ihrem Typfeld zugewiesen ist. Einige Typfeldwerte sind reserviert.
TLV oder Organisation |
Feld "Typ" |
|---|---|
TLV beenden |
0 |
Absender-ID: TLV |
1 |
TLV für Portstatus |
2 |
Daten-TLV |
3 |
Schnittstellenstatus TLV |
4 |
Antwort Ingress TLV |
5 |
Antwort Ausgang TLV |
6 |
LTM-Ausgangskennung TLV |
7 |
LTR-Ausgangskennung TLV |
8 |
Reserviert für IEEE 802.1 |
9 bis 30 |
Organisationsspezifischer 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 geeignet.
TLVs für die Continuity Check Message (CCM):
TLV beenden
Absender-ID: TLV
TLV für Portstatus
Schnittstellenstatus TLV
Organisationsspezifischer TLV
TLVs für Loopback-Nachrichten (LBM):
TLV beenden
Absender-ID: TLV
Daten-TLV
Organisationsspezifischer TLV
TLVs für Loopback-Antworten (LBR):
TLV beenden
Absender-ID: TLV
Daten-TLV
Organisationsspezifischer TLV
TLVs für Linktrace-Nachrichten (LTM):
TLV beenden
LTM-Ausgangskennung TLV
Absender-ID: TLV
Organisationsspezifischer TLV
TLVs, die für Linktrace Reply (LTR) gelten:
TLV beenden
LTR-Ausgangskennung TLV
Antwort Ingress TLV
Antwort Ausgang TLV
Absender-ID: TLV
Organisationsspezifischer TLV
Die folgenden TLVs werden derzeit in den entsprechenden CFM-PDUs unterstützt:
TLV beenden
Antwort Ingress TLV
Antwort Ausgang TLV
LTR-Ausgangskennung TLV
LTM-Ausgangskennung TLV
Daten-TLV
Unterstützung für zusätzliche optionale TLVs
Die folgenden zusätzlichen optionalen TLVs werden unterstützt:
TLV für Portstatus
Schnittstellenstatus TLV
Router der MX-Serie unterstützen die Konfiguration von TLV mit Portstatus und TLV mit Schnittstellenstatus. Die Konfiguration der Portstatus-TLV ermöglicht es dem Betreiber, die Übertragung der Portstatus-TLV in CFM-PDUs zu steuern.
Obwohl TLV-Konfigurationsanweisungen für den Portstatus in der CLI auf M120- und M320-Routern sichtbar sind, können die TLV-Anweisungen für den Portstatus auf diesen Systemen nicht konfiguriert werden. Die Portstatus-TLV kann auf einer MEP-Schnittstelle nur aktiviert werden, wenn es sich um eine logische Bridge-Schnittstelle handelt, was auf diesen Systemen nicht möglich ist.
Konfigurationsinformationen finden Sie in den folgenden Abschnitten:
TLV für Portstatus
Der Portstatus-TLV gibt die Fähigkeit des Bridge-Ports an, auf dem sich der sendende MEP befindet, normale Daten zu übergeben, unabhängig vom Status des MAC. Der Wert dieses TLV wird durch die Variable MEP gesteuert, wie in gezeigt.enableRmepDefectTabelle 4 Das Format dieser TLV wird in angezeigt.Tabelle 3
Jede Änderung des Werts für Portstatus-TLVs löst eine zusätzliche Übertragung der MEP-CCMs dieser Bridge-Ports aus.
Parameter |
Oktett (Sequenz) |
|---|---|
Typ = 2 |
1 |
Länge |
2–3 |
Wert (Siehe )Tabelle 4 |
4 |
Mnemonische |
Gewöhnliche Daten, die ungehindert durch den Port fließen |
Wert |
|---|---|---|
psBlockiert |
Nein: |
1 |
psUp |
Ja: |
2 |
Die MEP-Variable ist eine boolesche Variable, die angibt, ob Frames auf der Service-Instanz, die von den Wartungszuordnungen überwacht werden, wenn diese MEP durch das Spanning Tree Protocol und die VLAN-Topologieverwaltung für die Übertragung über diesen Bridge-Port aktiviert sind.enableRmepDefect Er wird auf TRUE gesetzt, wenn:
Der Bridge-Port wird in einen Zustand versetzt, in dem der Datenverkehr ihn passieren kann.
Auf dem Bridge-Port werden mehrere Instanzen des Spanning Tree ausgeführt.
Die MEP-Schnittstelle ist keiner Bridging-Domäne zugeordnet.
- Konfigurieren der TLV für den Portstatus
- Anzeige der TLV für den Status des empfangenen Ports
- Anzeige des übertragenen Portstatus TLV
Konfigurieren der TLV für den Portstatus
Junos OS bietet Konfigurationsunterstützung für die Portstatus-TLV, sodass Sie die Übertragung dieser TLV in CCM-PDUs steuern können. Das Junos-Betriebssystem stellt diese Konfiguration auf der Ebene der Kontinuitätsprüfung bereit. Standardmäßig enthält das CCM die Portstatus-TLV nicht. Um die TLV für den Portstatus zu konfigurieren, verwenden Sie die Anweisung auf Hierarchieebene .port-status-tlv[edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check]
Die TLV-Konfiguration für den Portstatus ist nicht durch IEEE 802.1ag vorgeschrieben. Das Junos-Betriebssystem bietet es, um dem Bediener mehr Flexibilität zu geben. Unabhängig von dieser Konfiguration empfängt und verarbeitet er jedoch CCMs mit einem Portstatus-TLV.
Im Folgenden finden Sie ein Beispiel für die Konfigurationsanweisungen:
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number,
loss-threshold number;
hold-interval number;
port-status-tlv; # Sets Port Status TLV
}
}
}
}
}
}
}
In den folgenden beiden Fällen können Sie die TLV-Übertragung für den Portstatus nicht aktivieren:
Wenn die MEP-Schnittstelle unter der Wartungszuordnung nicht vom Typ bridge ist.
Wenn der MEP auf einer physischen Schnittstelle konfiguriert ist.
Anzeige der TLV für den Status des empfangenen Ports
Das Junos-Betriebssystem speichert die zuletzt empfangene Portstatus-TLV von einem Remote-MEP. Wenn der empfangene Wert für den Portstatus nicht mit einem der Standardwerte übereinstimmt, die in aufgeführt sind, zeigt der Befehl ihn als "unbekannt" an.Tabelle 4show Sie können die zuletzt gespeicherte empfangene Portstatus-TLV mit dem Befehl anzeigen, wie im folgenden Beispiel gezeigt:show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none # RX PORT STATUS
Interface status TLV: none
Anzeige des übertragenen Portstatus TLV
Das Junos-Betriebssystem speichert die zuletzt übertragene Portstatus-TLV von einem lokalen MEP. Wenn die Übertragung der Portstatus-TLV nicht aktiviert wurde, zeigt der Befehl "none" an.show Sie können die zuletzt gespeicherte übertragene Portstatus-TLV mit dem Befehl anzeigen, wie im folgenden Beispiel gezeigt:show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up # TX PORT STATUS
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
Schnittstellenstatus TLV
Der Schnittstellenstatus-TLV gibt den Status der Schnittstelle an, auf der der MEP, der das CCM überträgt, konfiguriert ist, oder der nächstniedrigeren Schnittstelle im IETF RFC 2863 IF-MIB. Das Format dieser TLV wird in angezeigt.Tabelle 5 Die Aufzählungswerte werden in angezeigt.Tabelle 6
Parameter |
Oktett (Sequenz) |
|---|---|
Typ = 4 |
1 |
Länge |
2–3 |
Wert (Siehe )Tabelle 6 |
4 |
Mnemonische |
Schnittstellenstatus |
Wert |
|---|---|---|
isUp |
oben |
1 |
isDown |
nach unten |
2 |
isTesting |
Test |
3 |
isUnknown |
Unbekannt |
4 |
istInaktiv |
Ruhenden |
5 |
isNotPresent |
notPresent |
6 |
isLowerLayerDown |
lowerLayerDown |
7 |
Wenn sich der Betriebsstatus einer logischen Schnittstelle vom Down-Zustand (Statuswert 2) in den Down-Zustand der unteren Schicht (Statuswert 7) und umgekehrt ändert, wird der LinkDown-SNMP-Trap nicht generiert. Wenn Sie z. B. ein aggregiertes Ethernet-Schnittstellenpaket mit einem VLAN-Tag konfigurieren und dem Bündel eine physische Schnittstelle hinzufügen, die sich im betriebsbedingten Status befindet, ist der Betriebsstatus des aggregierten logischen Ethernet-Schnittstellenpakets an diesem Punkt die untere Ebene nach unten (7). Wenn Sie das MIC, das der Schnittstelle zugeordnet ist, offline schalten, wird der LinkDown-Trap nicht generiert, wenn die logische Schnittstelle vom Down-Zustand der unteren Ebene in den Down-Zustand wechselt.
Betrachten Sie in ähnlicher Weise ein anderes Beispielszenario, in dem eine physische Schnittstelle zu einem aggregierten Ethernet-Bundle hinzugefügt wird, das über VLAN-Tagging verfügt, und die aggregierte logische Ethernet-Schnittstelle deaktiviert ist. Wenn die logische Schnittstelle deaktiviert ist, ändert sich der Betriebsstatus der logischen Schnittstelle in "Nicht verfügbar". Wenn Sie die physische Schnittstelle deaktivieren, die Teil des aggregierten Ethernet-Pakets ist, bleibt der Betriebsstatus der aggregierten logischen Ethernet-Schnittstelle inaktiv. Wenn Sie die aggregierte logische Ethernet-Schnittstelle wieder aktivieren, ändert sich der Betriebsstatus von "down" zu "lower layer down". Der LinkDown-SNMP-Trap wird zu diesem Zeitpunkt nicht generiert.
- Konfigurieren der TLV für den Schnittstellenstatus
- Anzeige des empfangenen Schnittstellenstatus TLV
- Anzeige des übertragenen Schnittstellenstatus TLV
Konfigurieren der TLV für den Schnittstellenstatus
Das Junos-Betriebssystem bietet Konfigurationsunterstützung für den Schnittstellenstatus-TLV, sodass Betreiber die Übertragung dieses TLV in CCM-PDUs durch Konfiguration auf der Ebene der Durchgangsprüfung steuern können.
Diese Konfiguration ist nicht durch IEEE 802.1ag vorgeschrieben. Vielmehr wird es bereitgestellt, um dem Bediener mehr Flexibilität zu geben. Das Junos-Betriebssystem empfängt und verarbeitet CCMs mit dem Schnittstellenstatus-TLV, unabhängig von dieser Konfiguration.
Die TLV-Konfiguration für den Schnittstellenstatus wird unten angezeigt:
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number;
loss-threshold number;
hold-interval number;
interface-status-tlv; # Sets the interface status TLV
}
}
}
}
}
}
}
Das Junos-Betriebssystem 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-Betriebssystem ist jedoch in der Lage, einen beliebigen Wert für die Schnittstellenstatus-TLV zu empfangen.
Anzeige des empfangenen Schnittstellenstatus TLV
Das Junos-Betriebssystem speichert die zuletzt empfangene Schnittstellenstatus-TLV vom Remote-MEP. Wenn der empfangene Wert für den Schnittstellenstatus nicht mit einem der in aufgeführten Standardwerte übereinstimmt, zeigt der Befehl "unbekannt" an.Tabelle 5show
Sie können diese zuletzt gespeicherte Schnittstellenstatus-TLV mit dem Befehl anzeigen, wie im folgenden Beispiel gezeigt:show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none # displays the Interface Status TLV state
Anzeige des übertragenen Schnittstellenstatus TLV
Das Junos-Betriebssystem speichert die zuletzt übertragene Schnittstellenstatus-TLV von einem lokalen MEP. Wenn die Übertragung von Schnittstellenstatus-TLV nicht aktiviert wurde, zeigt der Befehl "none" an.show
Sie können die zuletzt übertragene Interface-Status-TLV mit dem Befehl anzeigen, wie im folgenden Beispiel gezeigt:show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
MAC-Status-Defekte
Das Junos-Betriebssystem stellt Informationen zu MAC-Statusfehlern bereit, die darauf hinweisen, dass einer oder mehrere der Remote-MEPs einen Fehler in der Portstatus- oder Schnittstellenstatus-TLV melden. Er zeigt "Ja" an, wenn entweder ein entfernter MEP meldet, dass seine Schnittstelle nicht isUp ist (z. B. wenn mindestens eine Remote-MEPs-Schnittstelle nicht verfügbar ist) oder wenn alle Remote-MEPs eine Portstatus-TLV melden, die einen anderen Wert als psUp enthält (z. B. leiten alle Remote-MEP-Bridge-Ports keine Daten weiter). Es gibt zwei Befehle, mit denen Sie die Anzeige "MAC-Statusmängel" anzeigen können.show
Verwenden Sie den Befehl, um MAC-Statusfehler anzuzeigen:mep-database
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6 maintenance-association ma6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1658
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Verwenden Sie den Befehl, um MAC-Statusfehler anzuzeigen:interfaces
user@host> show oam ethernet connectivity-fault-management interfaces detail
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
Interface status TLV: up, Port status TLV: up
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
MEP status: running
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1328
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Konfigurieren der Unterstützung von Remote-MEP-Aktionsprofilen
Basierend auf den Werten von und in den empfangenen CCM-Paketen kann mit den Optionen eine bestimmte Aktion, wie z. B . , ausgeführt werden.interface-status-tlvport-status-tlvinterface-downaction-profile Auf dem Router können mehrere Aktionsprofile konfiguriert werden, aber nur ein Aktionsprofil kann einem entfernten MEP zugewiesen werden.
Das Aktionsprofil kann mit mindestens einem Ereignis konfiguriert werden, um die Aktion auszulösen. Die Aktion wird jedoch ausgelöst, wenn eines dieser Ereignisse eintritt. Es ist nicht erforderlich, dass alle konfigurierten Ereignisse eintreten, um auszulösen .action
Ein Aktionsprofil kann nur auf der Ebene des entfernten MEP angewendet werden.
Das folgende Beispiel zeigt eine Aktionsprofilkonfiguration mit hinzugefügten erläuternden Kommentaren:
[edit protocols oam ethernet connectivity-fault-management]
action-profile tlv-action {
event {
# If interface status tlv with value specified in the config is received
interface-status-tlv down|lower-layer-down;
# If port status tlv with value specified in the config is received
port-status-tlv blocked;
# If connectivity is lost to the peer */
adjacency-loss;
}
action {
# Bring the interface down */
interface-down;
}
default-actions interface-down;
}
# domains
maintenance-domain identifier {
# maintenance domain level (0-7)
level number;
# association
maintenance-association identifier {
mep identifier {
interface ge-x/y/z.w;
remote-mep identifier {
# Apply the action-profile for the remote MEP
action-profile tlv-action;
}
}
}
}
Überwachen eines Remote-MEP-Aktionsprofils
Sie können den Befehl verwenden, um den Status des Aktionsprofils eines entfernten MEP anzuzeigen, wie im folgenden Beispiel gezeigt:show oam ethernet connectivity-fault-management mep-database
OAM-Ethernet-Konnektivitäts-Fehlermanagement anzeigen mep-database remote-mep (Aktionsprofil-Ereignis)
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 remote-mep 200
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 100, Direction: down, MAC address: 00:05:85:73:e8:ad
Auto-discovery: enabled, Priority: 0
Interface status TLV: none, Port status TLV: none # last status TLVs transmitted by the router
Interface name: ge-1/0/8.0, Interface status: Active, Link status: Up
Remote MEP identifier: 200, State: ok # displays the remote MEP name and state
MAC address: 00:05:85:73:96:1f, Type: Configured
Interface: ge-1/0/8.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: lower-layer-down
Action profile: juniper # displays remote MEP’s action profile identifier
Last event: Interface-status-tlv lower-layer-down # last remote MEP event
# to trigger action
Action: Interface-down, Time: 2009-03-27 14:25:10 PDT (00:00:02 ago)
# action occurrence time
Konfigurieren der Chassis-ID-TLV
In Version 16.1R2 und höher können Sie Junos OS so konfigurieren, dass die Absender-ID-TLV zusammen mit den Paketen gesendet wird. Die Sender-ID-TLV ist eine optionale TLV, die in Continuity Check Messages (CCMs), Loopback-Nachrichten und Link Trace Messages (LTMs) gesendet wird, wie im IEEE 802.1ag-Standard spezifiziert. Die Sender-ID-TLV enthält die Chassis-ID, bei der es sich um die eindeutige, CFM-basierte MAC-Adresse des Geräts handelt, und die Verwaltungs-IP-Adresse, bei der es sich um eine IPv4- oder IPv6-Adresse handelt.
Der Wert des Feldes in der TLV gibt an, ob die TLV die Chassis-ID-Informationen enthält oder nicht.length Die möglichen Werte für das Feld sind Null () oder eine beliebige gültige Zahl, die das Fehlen bzw. Vorhandensein von Fahrgestell-ID-Informationen im TLV angibt.length0
Mit dem Befehl können Sie Junos OS aktivieren, um die Absender-ID-TLV auf globaler Ebene zu senden.set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv Wenn die Absender-ID-TLV auf globaler Ebene konfiguriert ist, erben die Standardwartungsdomäne, die Wartungszuordnung und die MIP-Halbfunktion (Maintenance Association Intermediate Point) 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 Wartungszuordnungsebene hat Vorrang vor der Konfiguration auf globaler Ebene.
Die Absender-ID-TLV wird nur für 802.1ag-PDUs und nicht für PDUs (Performance Monitoring Protocol Data Units) unterstützt.
Siehe auch
MAC Flush Message Processing im CET-Modus konfigurieren
Im Carrier-Ethernet-Transportmodus (CET) werden Router der MX-Serie als Provider-Edge-Router (PE) verwendet, und auf der Zugriffsseite werden Nokia Siemens Networks A2200 Carrier-Ethernet-Switches (als E-Domain-Geräte bezeichnet) verwendet, auf denen standardbasierte Protokolle ausgeführt werden. Auf den Routern der MX-Serie werden VPLS-Pseudowires dynamisch über das Label Distribution Protocol (LDP) konfiguriert. Auf den 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 Ethernet-Schnittstelle des Netzbetreibers bei einem Verlust der CFM-Konnektivität zum Absturz bringen. Dies löst eine lokale MAC-Flush-Benachrichtigung sowie eine T-LDP-MAC-Flush-Benachrichtigung (Targeted Label Distribution Protocol) aus, die an die Remote-PEs der MX-Serie gesendet wird, um eine MAC-Flush-Benachrichtigung für diese auszulösen.
Im CET-Inter-Op-Modus müssen Router der MX-Serie mit den Ax100 Carrier-Ethernet-Zugangsgeräten von Nokia Siemens Networks (als A-Domain-Geräte bezeichnet) zusammenarbeiten, auf denen ältere Protokolle ausgeführt werden. Die A4100- und A8100-Geräte von Nokia Siemens Networks fungieren als Zwischenprodukt zwischen den PE-Routern der MX-Serie und den A-Domain-Geräten. Diese Zwischengeräte führen IWF-Verfahren (Interworking Function) durch, sodass OAM-Sitzungen (Operations Administration Management) zwischen Routern der MX-Serie und A-Domain-Geräten ausgeführt werden können. Es gibt keine VPLS-Pseudowires zwischen den PE-Routern der MX-Serie und den Nokia Siemens Networks A4100- und A8100-Zwischengeräten, sodass kein LDP-Protokoll zwischen den PE-Routern ausgeführt wird, um Benachrichtigungen über Topologieänderungen zu senden. Um Topologieänderungen zu kommunizieren, können Router der MX-Serie einen MAC-Flush auslösen und im Core weitergeben. Router der MX-Serie können Aktionsprofile verwenden, die auf dem TLV-Ereignis (Connection Protection Type Length Value) basieren. Das Aktionsprofil schaltet die logische Carrier-Edge-Schnittstelle in PE-Routern der MX-Serie aus, wodurch eine lokale MAC-Leerung ausgelöst wird und die Topologieänderung mithilfe einer LDP-Benachrichtigung an den Core weitergegeben wird.
Für VPLS wird keine End-to-End-Konnektivität überwacht. Die Zugriffsringe werden unabhängig voneinander überwacht, indem CFM über mehrere Endpunkte (MEPs) auf den Arbeits- und Schutzpfaden für jeden der Dienste zwischen den E-Domain-Geräten und den PE-Routern der MX-Serie sowie zwischen den A-Domain-Geräten und den PE-Routern der MX-Serie (IWF) ausgeführt wird, die von den A-4100-Geräten von Nokia Siemens Networks gehostet werden. Wenn auf dem Arbeitspfad ein Verbindungsfehler auftritt, schalten die Ax200-Geräte von Nokia Siemens Networks auf den Schutzpfad um und lösen eine Benachrichtigung über eine Änderung der Topologie (in Form von TLVs, die in CCM übertragen werden) aus, die an den aktiven Pfad gesendet wird.
Abbildung 1 beschreibt die Dual Homed Topologie auf PE-Routern der MX-Serie, die mit der A-Domäne verbunden sind. Wenn ein A-Domain-Gerät einen Switchover auslöst, beginnt es, den Dienstdatenverkehr auf den neuen aktiven Pfad umzuschalten. Diese Änderung wird in den HELLO-Protokolldateneinheiten (PDUs) kommuniziert, die von diesem A-Domänen-Gerät auf den Arbeits- und Schutzpfaden gesendet werden. Wenn das IWF in A4100 diese HELLO-PDUs empfängt, wandelt es sie in Standard-CCM-Nachrichten um und fügt außerdem ein Verbindungsschutz-TLV ein. Das Feld "Protection-in-use" des Verbindungsschutz-TLV ist mit dem aktuell aktiven Pfad kodiert und in der CCM-Nachricht enthalten. CCM-Nachrichten werden von den PE-Routern der MX-Serie über den VLAN-Spoke im 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.
Eine MAC-Leerung erfolgt, wenn die CFM-Sitzung, die den Arbeitspfad überwacht, erkennt, dass der Dienstdatenverkehr in den Schutzpfad verschoben wurde, oder wenn die CFM-Sitzung, die den Schutzpfad überwacht, erkennt, dass der Dienstdatenverkehr in den Arbeitspfad verschoben wurde.
Abbildung 2 beschreibt die Dual-Attached-Topologie auf PE-Routern der MX-Serie, die mit der A-Domäne verbunden sind. Der MAC-Flush-Mechanismus, der in diesem Fall verwendet wird, ist ebenfalls derselbe wie der, der für die A-Domäne im Dual-Homed-Szenario verwendet wird (Abbildung 1). In diesem Fall werden jedoch beide CFM-Sitzungen von nur einem PE-Router der MX-Serie gehostet. Wenn Ax100 in der A-Domäne Änderungen an der Topologie feststellt, empfängt der PE-Router der MX-Serie die TLV für den Verbindungsschutz in der CCM-Nachricht für die Arbeits- und Schutzpfade mit dem Wert "Protection-in-use", der angibt, welcher Pfad der aktive ist. Basierend auf dem Ereignis, das für die CFM-Sitzung generiert wird, schaltet der PE-Router der MX-Serie die entsprechende Schnittstelle herunter, wodurch eine lokale MAC-Leerung ausgelöst wird.
Konfigurieren eines TLV-Aktionsprofils für den Verbindungsschutz
Ein Aktionsprofil kann so konfiguriert werden, dass die Aktion basierend auf den Werten von in den empfangenen CCM-Paketen ausgeführt wird.interface-downconnection-protection-tlv
Das folgende Beispiel zeigt eine Aktionsprofilkonfiguration mit hinzugefügten erläuternden Kommentaren:
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
# If a connection protection TLV with a “Protection-in-use” value of SET is received */
connection-protection-tlv <using-protection-path>;
# If a connection protection TLV with a “Protection-in-use” value of RESET is received */
connection-protection-tlv <using-working-path>;
}
action {
# Bring the interface down */
interface-down;
}
}
Siehe auch
Beispiel: Konfigurieren eines Aktionsprofils basierend auf Verbindungsschutz-TLVs
In diesem Beispiel wird gezeigt, wie ein Aktionsprofil basierend auf der TLV für den Verbindungsschutz konfiguriert wird, um MAC-Leerungen 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
Übersicht und Topologie
Die physikalische Topologie eines CET-Netzwerks mit PE-Routern der MX-Serie ist in Abbildung 3
Topologie
Die folgenden Definitionen beschreiben die Bedeutung des Gerätekürzels und die in .Abbildung 3
Provider Edge (PE)-Gerät: Ein Gerät oder eine Gruppe von Geräten am Edge des Provider-Netzwerks, das die Ansicht des Anbieters auf den Kundenstandort darstellt.
E-Domain: Nokia Siemens Networks Carrier Ethernet-Switches, die standardbasierte Protokolle ausführen und auf der Zugriffsseite verwendet werden.
A-Domäne: Nokia Siemens Networks Carrier Ethernet-Switches, auf denen ältere Protokolle ausgeführt werden.
Konfiguration
Verfahren
Schritt-für-Schritt-Anleitung
Führen Sie die folgenden Aufgaben aus, um ein Aktionsprofil basierend auf der TLV für den Verbindungsschutz zu konfigurieren:
Konfigurieren eines Aktionsprofils
[edit protocols oam ethernet connectivity-fault-management] action-profile <tlv-action> { event {Wenn die TLV für den Verbindungsschutz mit dem Wert "Protection-in-use" von SET empfangen wird, sollte die TLV für den Verbindungsschutz den Schutzpfad verwenden
connection-protection-tlv <using-protection-path>;
Wenn die TLV für den Verbindungsschutz mit dem Wert "Protection-in-use" von RESET empfangen wird, sollte der TLV für den Verbindungsschutz den Arbeitspfad verwenden
connection-protection-tlv <using-working-path>; }
Konfigurieren Sie das Aktionsprofil, um die Benutzeroberfläche herunterzufahren
action { /* Bring the interface down */ interface-down; } }
Ergebnisse
Überprüfen Sie die Ergebnisse der Konfiguration
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
connection-protection-tlv <using-protection-path>;
connection-protection-tlv <using-working-path>;
}
action {
interface-down;
}
}
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.