Auf dieser Seite
Konfigurieren eines CFM-Aktionsprofils für Asyncronus-Benachrichtigung
Grundlegendes zur CFM-Überwachung zwischen CE- und PE-Geräten
Konfigurieren vonTLV für Portstatus und TLV für Schnittstellenstatus
Konfigurieren der MAC-Flush-Nachrichtenverarbeitung im CET-Modus
Beispiel: Konfigurieren eines Aktionsprofils basierend auf TLVs für den Verbindungsschutz
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 TLVs für den Schnittstellenstatus, Portstatus, Gehäuse-ID-TLVs und TLVs für den Verbindungsschutz bei der Überwachung Ihres Netzwerks hilfreich sind.
Asynchrone Benachrichtigung über CFM-Aktionsprofile
Die 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ätenausgeht. Es simuliert das Szenario, als ob zwei CE-Geräte direkt 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 ausfällt, sinkt auch die Verbindung zwischen PE1 und CE1. Wenn die Verbindung wiederhergestellt wird, wird der Verbindungsstatus zwischen PE1 und CE1wiederhergestellt . Die Änderung des Verbindungsstatus zwischen PE1 und CE1 sollte ähnlichfunktionieren.
-
Wenn es ein Konnektivitätsproblem zwischen PE1 und PE2 gibt, wird eine Verbindung zwischen PE1 und CE1 sowie PE2 und 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-Benachrichtigung
CFM UP-MEP auf PE1 und PE2, überwacht die Konnektivität zwischen PE1 und PE2. Die interface-status-tlv an diesen UP-MEP-Endpunkten vermitteln den Verbindungsstatus zwischen PE1, CE1und PE2 sowie zwischen PE2, CE2und PE1. Sie müssen das Aktionsprofil auf PE1 bis PE2 konfigurieren, um asynchrone Benachrichtigungen an die jeweiligen CE-Geräte zu senden. Das Aktionsprofil löst diese Benachrichtigungen aus, wenn das System einen Nachbarschaftsverlust oder eine Verknüpfungsbedingung in der empfangenen interface-status-tlverkennt.
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 ausfällt, gibt CFM den Status der Schnittstelle in den CC-Nachrichten weiter. Die CC-Meldung benachrichtigt das Kunden-Edge-Gerät, dass das Provider-Edge-Gerät 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 ausfällt, gibt CFM den Status der Schnittstelle über den Schnittstellenstatus-TLV weiter. Der TLV für den Schnittstellenstatus gibt den Status der Schnittstelle an, die den MEP hostet, der das CCM überträgt, oder es gibt die nächstniedrigere Schnittstelle in IETF RFC 2863 IF-MIB an. Somit erfährt das Kunden-Edge-Gerät, dass das Provider-Edge-Gerät ausgefallen ist. Um die CFM-Überwachung mit Interface Status TLV zu konfigurieren, verwenden Sie die
interface-status-tlvAnweisung auf Hierarchieebene[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check. Diese Konfiguration ist die Standardoption.RDI (Remote Defect Indication): Mithilfe des RDI-Bits können Sie die Überwachung des Connectivity Fault Management (CFM) zwischen Provider-Edge-Geräten und Kunden-Edge-Geräten aktivieren, wenn das Kunden-Edge-Gerät kein Juniper Gerät ist. Wenn Sie die CFM-Überwachung aktivieren, gibt CFM den Status des Provider-Edge-Geräts über das RDI-Bit in den CC-Meldungen weiter, wodurch das Kunden-Edge-Gerät darüber informiert wird, dass das Provider-Edge-Gerät 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
interface-status-send-rdiAnweisung auf Hierarchieebene[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check. Diese Option ist erforderlich, wenn das Kunden-Edge-Gerät die Schnittstellenstatus-TLV nicht unterstützt.
Wenn Sie die Schnittstelle auf CCC einstellen und RDI konfigurieren, sendet das Gerät das RDI-Bit. CFM überwacht den Schnittstellenstatus nicht.
Wenn Sie CCC ausschalten, während sich die Schnittstelle nicht im Standby-Modus befindet, und RDI konfigurieren, schließt das Gerät das RDI-Bit in CC-Nachrichten ein.
- Einzelner aktiver Multi-Homing-Anwendungsfall mit RDI-Bit
- Aktiv/Aktiv-Multihoming Anwendungsszenario mit RDI-Bit
Einzelner aktiver Multi-Homing-Anwendungsfall mit RDI-Bit
Betrachten Sie die folgende Topologie, die zwei Provider-Edge-Geräte (PE1 und PE2) und zwei Kunden-Edge-Geräte (CE1 und CE2) umfasst. PE1 arbeitet im aktiven Zustand, während PE2 im Standby-Zustand bleibt. Wenn Sie CFM down MEP zwischen PE und CE konfigurieren, erkennt CFM, dass der CCC ausgefallen ist, und das System nimmt das RDI-Bit in die CC-Nachrichten auf. In den CC-Nachrichten von PE2 bis CE2 ist das RDI-Bit so eingestellt, dass es den blockierten Zustand anzeigt. Wenn PE2 aktiv wird, löscht das System den Status CCM down und entfernt das RDI-Bit aus nachfolgenden CC-Meldungen.
Aktiv/Aktiv-Multihoming Anwendungsszenario mit RDI-Bit
Betrachten Sie die folgende Topologie, die zwei Provider-Edge-Geräte (PE1 und PE2) und zwei Kunden-Edge-Geräte (CE1 und CE2) umfasst. PE1 arbeitet im aktiven Zustand, während PE2 im Standby-Zustand bleibt. Wenn Sie CFM nicht zwischen PE und CE konfigurieren, um die Verbindungskonnektivität zu überwachen, nimmt das System das RDI-Bit nicht in die CC-Nachrichten auf. Wenn Sie CFM down MEP zwischen PE und CE konfigurieren, erkennt CFM, dass der CCC ausgefallen ist, und das System nimmt das RDI-Bit in die CC-Nachrichten auf. In den CC-Nachrichten von PE2 bis CE2 ist das RDI-Bit so eingestellt, dass es den blockierten Zustand anzeigt. Wenn PE2 aktiv wird, löscht das System den Status CCM down und entfernt das RDI-Bit aus nachfolgenden CC-Meldungen.
Siehe auch
Konfigurieren vonTLV für Portstatus und TLV für Schnittstellenstatus
- TLVs im Überblick
- Verschiedene TLVs für CFM-PDUs
- Unterstützung für zusätzliche optionale TLVs
- MAC-Status-Defekte
- Unterstützung für Remote-MEP-Aktionsprofile konfigurieren
- Überwachen eines Remote-TGA-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 |
|---|---|---|
Art |
1 |
Dieses Feld muss ausgefüllt werden. Wenn der Wert 0 ist, folgen keine weiteren Felder (Länge oder Wert). Wenn der Wert nicht 0 ist, muss das Feld Länge folgen. |
Länge |
2–3 |
Dieses Feld ist nur erforderlich, wenn das Feld Typ nicht 0 ist. Er ist nicht vorhanden, wenn das Feld Typ 0 ist. Die 16 Bits des Felds Länge geben die Größe des Felds Wert in Oktetten an. Ein Längenfeldwert von 0 bedeutet, dass kein Wertfeld vorhanden ist. |
Wert |
4 |
Die Länge dieses Feldes wird durch das Feld Länge angegeben. Er ist optional und wird nicht angezeigt, wenn das Feld Typ 0 oder das Feld Länge 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 Feld Typ zugewiesen ist. Einige Typ-Feldwerte 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.
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 enableRmepDefectMEP gesteuert, wie in gezeigt. Tabelle 4 Das Format dieser TLV wird in Tabelle 3angezeigt.
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 |
Mnemonisch |
Gewöhnliche Daten, die ungehindert durch den Port fließen |
Wert |
|---|---|---|
psBlockiert |
Nein: |
1 |
psUp |
Ja: |
2 |
Die MEP-Variable enableRmepDefect ist eine boolesche Variable. Sie gibt an, ob Frames auf der Dienstinstanz, die von den Wartungszuordnungen des MEP überwacht werden, den Bridge-Port mithilfe des Spanning Tree Protocols und der VLAN-Topologieverwaltung passieren können. 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 des TLV für Portstatus
- TLV für den Status des empfangenen Ports anzeigen
- TLV für den Status des übertragenen Ports anzeigen
Konfigurieren des TLV für Portstatus
Junos OS bietet Konfigurationsunterstützung für das TLV "Port Status", sodass Sie die Übertragung des 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 port-status-tlv Anweisung auf Hierarchieebene [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 OS bietet diese Konfiguration, um dem Betreiber mehr Flexibilität zu bieten. Er empfängt und verarbeitet jedoch CCMs mit einem Portstatus-TLV, unabhängig von der Konfiguration.
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.
TLV für den Status des empfangenen Ports anzeigen
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 Tabelle 4aufgeführt sind, zeigt der show Befehl ihn als "unbekannt" an. Sie können die zuletzt gespeicherte empfangene Portstatus-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, wie im folgenden Beispiel gezeigt:
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
TLV für den Status des übertragenen Ports anzeigen
Das Junos-Betriebssystem speichert die zuletzt übertragene Portstatus-TLV von einem lokalen MEP. Wenn die Übertragung der Portstatus-TLV nicht aktiviert wurde, zeigt der show Befehl "none" an. Sie können die zuletzt gespeicherte übertragene Portstatus-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, wie im folgenden Beispiel gezeigt:
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 Tabelle 5angezeigt. Die Aufzählungswerte werden in Tabelle 6angezeigt.
Parameter |
Oktett (Sequenz) |
|---|---|
Typ = 4 |
1 |
Länge |
2–3 |
Wert (Siehe Tabelle 6) |
4 |
Mnemonisch |
Schnittstellenstatus |
Wert |
|---|---|---|
isUp |
oben |
1 |
isDown |
herab |
2 |
isTesting |
Testen |
3 |
isUnknown |
unbekannt |
4 |
istInaktiv |
schlafend |
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 des Schnittstellenstatus TLV
- Anzeigen des TLV für den Status der empfangenen Schnittstelle
- TLV für den Status der übertragenen Schnittstelle anzeigen
Konfigurieren des Schnittstellenstatus TLV
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.
Anzeigen des TLV für den Status der empfangenen Schnittstelle
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 Tabelle 5aufgeführten Standardwerte übereinstimmt, zeigt der show Befehl "unbekannt" an.
Sie können diese zuletzt gespeicherte 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, wie im folgenden Beispiel gezeigt:
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
TLV für den Status der übertragenen Schnittstelle anzeigen
Das Junos-Betriebssystem speichert die zuletzt übertragene Schnittstellenstatus-TLV von einem lokalen MEP. Wenn die Übertragung von Schnittstellenstatus-TLV nicht aktiviert wurde, zeigt der show Befehl "none" an.
Sie können die zuletzt übertragene Interface-Status-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, wie im folgenden Beispiel gezeigt:
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 OS stellt Informationen zu MAC-Statusdefekten bereit, die anzeigen, wenn entfernte MEPs Fehler in ihrem Portstatus-TLV oder Schnittstellenstatus-TLV melden. Das System zeigt "Ja" an, wenn ein oder mehrere Remote-MEPs melden, dass ihre Schnittstelle nicht "Up" ist (z. B. wenn die Schnittstelle eines Remote-MEPs nicht verfügbar ist) oder wenn alle Remote-MEPs einen Portstatus-TLV mit einem anderen Wert als "Up" melden (z. B. wenn die Bridge-Ports aller Remote-MEPs keine Daten weiterleiten). Sie können die Anzeige für MAC-Statusfehler mit zwei show Befehlen anzeigen.
Verwenden Sie den mep-database Befehl, um MAC-Statusfehler anzuzeigen:
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 interfaces Befehl, um MAC-Statusfehler anzuzeigen:
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
Unterstützung für Remote-MEP-Aktionsprofile konfigurieren
Basierend auf den Werten von interface-status-tlv und port-status-tlv in den empfangenen CCM-Paketen kann mit den Optionen eine bestimmte Aktion, wie z. B interface-down. , action-profile ausgeführt werden. Auf dem Router können mehrere Aktionsprofile konfiguriert werden, aber nur ein Aktionsprofil kann einem entfernten MEP zugewiesen werden.
Das Aktionsprofil kann mit einem oder mehreren Ereignissen konfiguriert werden, und die Aktion wird ausgelöst, wenn eines dieser Ereignisse eintritt. Es ist nicht erforderlich, dass alle konfigurierten Ereignisse ausgelöst actionwerden.
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-TGA-Aktionsprofils
Sie können den show oam ethernet connectivity-fault-management mep-database Befehl verwenden, um den Status des Aktionsprofils eines entfernten MEP anzuzeigen, wie im folgenden Beispiel gezeigt:
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
Sie können Junos OS so konfigurieren, dass die Sender ID-TLV zusammen mit den Paketen gesendet wird. Der Sender ID-TLV ist ein optionaler TLV, der in Form von Continuity Check Messages (CCMs), Loopback-Messages und Link Trace Messages (LTMs) gesendet wird, wie im IEEE 802.1ag-Standard spezifiziert. Die Absender-ID-TLV enthält die Chassis-ID, also die eindeutige, CFM-basierte MAC-Adresse des Geräts, und die Verwaltungs-IP-Adresse, bei der es sich um eine IPv4- oder IPv6-Adresse handelt.
Der Wert des length Feldes in der TLV gibt an, ob die TLV die Chassis-ID-Informationen enthält oder nicht. Die möglichen Werte für das length Feld sind Null (0) oder eine beliebige gültige Zahl, die das Fehlen bzw. Vorhandensein von Fahrgestell-ID-Informationen im TLV angibt.
Mit dem set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv folgenden Befehl können Sie Junos OS zum Senden der Sender ID-TLV auf globaler Ebene aktivieren. Wenn die TLV der Sender ID 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 der maintenance-association Ebene hat Vorrang vor der Konfiguration auf globaler Ebene.
Die Sender ID-TLV wird nur für 802.1ag-PDUs und nicht für PDUs (Performance Monitoring Protocol Data Units) unterstützt.
Siehe auch
Konfigurieren der MAC-Flush-Nachrichtenverarbeitung im CET-Modus
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 interface-down Aktion basierend auf den Werten von connection-protection-tlv in den empfangenen CCM-Paketen ausgeführt wird.
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 TLVs für den Verbindungsschutz
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 physische Topologie eines CET-Netzwerks mit PE-Routern der MX-Serie ist in Abbildung 3dargestellt.
Topologie
Die folgenden Definitionen beschreiben die Bedeutung des Gerätekürzels und die in Abbildung 3.
Provider-Edge-Gerät (PE): Ein Gerät oder eine Gruppe von Geräten am Edge des Anbieternetzwerks, 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.