Fehlerbehebung bei Alarmen auf physischen Ebenen auf SONET- und SDH-Links

Einführung

In diesem Dokument werden allgemeine SONET-Alarme und deren Behebung erläutert.

Bei der Alarmüberwachung werden zwei Begriffe verwendet:

• State (Status): Zustand, der gemeldet oder erkannt wird. Ein SONET-Gerät wechselt in den Status, wenn das Gerät das Auftreten eines Ereignisses erkennt. Ein SONET-Gerät verlässt diesen Status, wenn das Gerät das Ereignis nicht mehr erkennt. In diesem Dokument wird der Verlust von Signal (LOS) und der Verlust von Frame-Zuständen (LOF) erläutert.

• Indication (Anzeige) - Wird durch eine Statusänderung ausgelöst. Dies weist auf das Vorhandensein einer Bedingung hin. In diesem Dokument werden das Alarmanzeigesignal (AIS), die Fernfehleranzeige (RDI) und die FERF-Meldungen (Failover Receive Failure) erläutert.

Aktive Alarme oder Fehler halten eine Schnittstelle im Down/Down-Status. Der Prozess zur Fehlerbehebung für SONET-Schnittstellen (Down/Down) ähnelt dem für digitale Schnittstellen (z. B. T1 und T3).

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Alarme auf SONET-Schichten

SONET-Geräte erkennen Ereignisse und Alarme auf jeder der drei Ebenen von SONET - Abschnitt, Leitung und Pfad. In der Regel sendet ein SONET-Gerät Alarme sowohl an den Upstream- als auch an den Downstream-Bereich, um andere Geräte über den Problemzustand zu informieren.

Geben Sie den Befehl pos report ein, um die Alarme zu konfigurieren, die die POS-Schnittstelle (Packet over SONET) aktivieren kann.

RTR12410-1(config)#interface pos 2/1
   RTR12410-1(config-if)#pos report ? 
  all     all Alarms/Signals 
  b1-tca  B1 BER threshold crossing alarm 
  b2-tca  B2 BER threshold crossing alarm 
  b3-tca  B3 BER threshold crossing alarm 
  lais    Line Alarm Indication Signal 
  lrdi    Line Remote Defect Indication 
  pais    Path Alarm Indication Signal 
  plop    Path Loss of Pointer 
  prdi    Path Remote Defect Indication 
  rdool   Receive Data Out Of Lock 
  sd-ber  LBIP BER in excess of SD threshold 
  sf-ber  LBIP BER in excess of SF threshold 
  slof    Section Loss of Frame 
  slos    Section Loss of Signal

Der Befehl show controller zeigt an, wie oft ein Alarm deklariert wird und ob Alarme auf einem POS- und ATM-Gerät über SONET-Schnittstelle aktiv sind. Diese Ausgabe wurde auf einem Gigabit Switch Router (GSR) erfasst. Der Abschnitt "Aktive Defects" (Aktive Defekte) zeigt an, was die lokale Schnittstelle sieht. Der Abschnitt Aktive Alarme zeigt an, was das Upstream-Gerät meldet.

RTR12410-1#show controller pos 1/0
POS1/0 
SECTION 
  LOF = 1         LOS    = 1                       BIP(B1) = 31165 
LINE 
  AIS = 1         RDI    = 0     FEBE = 0          BIP(B2) = 0 
PATH 
  AIS = 1         RDI    = 1     FEBE = 0          BIP(B3) = 25614 
  LOP = 0         NEWPTR = 1     PSE  = 0          NSE     = 0 
Active Defects: SLOF SLOS B1-TCA LAIS PAIS PRDI B3-TCA 
Active Alarms:  SLOS B1-TCA B3-TCA 
Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA

Diese Beispielausgabe wurde auch aus einem GSR erfasst. Die LINK-3-UPDOWN-Meldung weist darauf hin, dass die physische Ebene aktiv ist und dass alle aktiven Alarme jetzt eindeutig sind. Die LINEPROTO-5-UPDOWN-Meldung weist darauf hin, dass das Verbindungsprotokoll aktiviert ist. Das Leitungsprotokoll an POS-Schnittstellen ist Frame Relay, High Level Data Link Control (HDLC) oder Point-to-Point Protocol (PPP).

Aug  7 05:14:37 BST: %LINK-3-UPDOWN: Interface POS4/7, changed state 
     to up 
     Aug  7 05:14:38 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
     POS4/7,changed state to up 
     Aug  7 05:14:49 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:14:52 BST: %SONET-4-ALARM:  POS4/7: LRDI 
     Aug  7 05:15:02 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
     POS4/7, changed state to down 
     
! --- Router receives the Line Remote Defect Indicator (LRDI) ! --- and brings down the line protocol.
 
      
     Aug  7 05:15:13 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:16:42 BST: %SONET-4-ALARM:  POS4/7: LRDI 
     Aug  7 05:16:45 BST: %SONET-4-ALARM:  POS4/7: SLOS 
     Aug  7 05:16:47 BST: %LINK-3-UPDOWN: Interface POS4/7, changed state 
     to down 
     Aug  7 05:16:56 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:16:56 BST: %SONET-4-ALARM:  POS4/7: PRDI 
     Aug  7 05:17:49 BST: %SONET-4-ALARM:  POS4/7: LRDI

Hinweis: Um präzise Zeitstempel für Protokollmeldungen zu erfassen, konfigurieren Sie den Befehl service timestamps log datetime msec.

Ein Router mit ATM over SONET-Schnittstellen meldet ebenfalls aktive Alarme mit diesen Protokollmeldungen:

Feb 18 16:34:22.309: %SONET-4-ALARM: ATM5/0: ~SLOF SLOS LAIS ~LRDI PAIS PRDI ~PLOP

Das "~"-Zeichen zeigt an, dass der jeweilige Alarm nicht aktiv ist, und das Fehlen des "~"-Zeichens zeigt an, dass der Alarm aktiv ist. In dieser Beispielausgabe gibt ~SLOF an, dass keine Abschnittsverluste bei Frame-Fehlern auftreten. Die Schnittstelle verfügt jedoch über mehrere weitere aktive Alarme, darunter SLOS (Section Loss of Signal) und LAIS (Line Alarm Signal).

Alarmanzeigen

In der Regel führt ein von einem SONET-Gerät erkannter Fehlerzustand dazu, dass eine oder mehrere Fehlerzustände sowohl vor- als auch nachgeschaltet auf das Netzwerk übertragen werden. Ein AIS wird gesendet, um nachgeschaltete Geräte auf ein Problem hinzuweisen und zu verhindern, dass Folgeschäden oder Alarme ausgelöst werden. Ein RDI-Alarm wird als Kontroll- und Feedback-Mechanismus für das Netzwerk an den Upstream gesendet. FDI wurde zuvor als FERF bezeichnet.

Die RDI unterscheidet sich von der Remote Error Indicator (REI). Die REI kommuniziert Leistungsüberwachungswerte wie Bitfehlerraten.

Fehlerbehebung

Verwenden Sie diese Tabelle, um SONET-Alarme zu isolieren und zu beheben. Beachten Sie bei der Fehlerbehebung die SONET-Ebene, auf der Fehler und Alarme erkannt werden. Führen Sie beispielsweise einen erweiterten Test der End-to-End-Verbindung durch, wenn die POS-Schnittstellen nur Pfadschichtfehler melden. Beachten Sie auch, was die Upstream- und Remote-Geräte sehen.

router(config-if)# [no] pos framing-sdh

Fehlerbehebung mit Loopback-Befehlen

Mit dem Loopback-Test können Sie die Verbindung zwischen der OC-3-Schnittstelle und einem Remote-Gerät testen, um Gerätefehler zu beheben, zu erkennen und zu isolieren. Der Loopback-Befehl platziert eine Schnittstelle im internen Loopback-Modus (auch als lokales Loopback bezeichnet) oder im Line-Loopback-Modus, mit dem Testpakete, die vom Ping-Befehl generiert werden, durch ein Remote-Gerät oder ein Kabel schleifen können. Wenn die Pakete die Schleife abschließen, ist die Verbindung gut. Andernfalls können Sie einen Fehler am Remote-Gerät oder am Kabel im Pfad des Loopback-Tests isolieren.

Mit internem Loopback beachten Sie:

• Wenn Sie ein Loopback konfigurieren, stellen Sie sicher, dass Sie die Schnittstelle für die interne Taktgebung mit dem internen Befehl clock source konfigurieren. Der Framer wartet auf eingehende gültige Frames, mit denen synchronisiert werden soll, und verwendet diese Frames zur Zeit seiner Übertragung, wenn sie für die Taktquelle konfiguriert sind. Ohne Empfangs-Frames haben Sie kein Timing zum Senden von Frames.

• Wenn man eine Hardware-Schleife durchführt, also einfach die Glasfaser wieder in die Schnittstelle einbindet, stellen Sie sicher, dass Sie einen Dämpfer verwenden, wenn Sie eine Single-Mode-Schnittstelle verwenden. Wenn nicht, können Sie die Schnittstelle mit zu viel Strom überlasten oder die optischen Verbindungen auf der Karte beschädigen, wenn es sich um eine Long Reach-Karte handelt oder wenn die Übertragung höhere Werte als die Nennwerte sendet.

Konfigurieren einer Schnittstelle für die interne Loopback-Funktion

Die Loopback-Standardeinstellung ist "no loopback" (Kein Loopback). Bei einem internen (oder lokalen) Loopback werden Pakete vom Router im Framer zurückgeschleift. Ausgehende Daten werden ohne Weiterleitung an den Empfänger zurückgeleitet. Das interne Loopback ist nützlich, wenn Sie überprüfen möchten, ob die POS-Schnittstelle funktioniert. Um eine Schnittstelle für das interne Loopback zu konfigurieren, führen Sie den schleifeninternen Befehl aus:

Router(config)#interface pos 3/0
Router(config-if)#loop internal

Konfigurieren einer Schnittstelle für Line Loopback

Die Loopback-Standardeinstellung ist "no loopback" (Kein Loopback). Bei einem Line-Loopback wird die Receiver-Glasfaser (Rx) logisch mit dem optischen Übertragungskabel (Tx) verbunden, sodass Pakete vom Remote-Router an das Kabel zurückgeleitet werden. Eingehende Daten werden umhergeschleift und neu übertragen, ohne dass sie tatsächlich empfangen werden. Um eine Schnittstelle für das Line-Loopback zu konfigurieren, führen Sie den Befehl Loop Line aus:

Router(config)#interface pos 3/0
Router(config-if)#loop line

Hinweis: Der Befehl loopback line schleift das Signal vor dem SONET-Framer.

Konfigurieren von SONET-Delay-Triggern

Ein Trigger ist ein Alarm, der bei der Assertion dazu führt, dass das Verbindungsprotokoll ausfällt. In diesen Abschnitten werden die Zeilenauslöser und Pfadauslöser erläutert, die Sie mit dem Befehl POS-Verzögerungs-Trigger konfigurieren.

RTR12410-1(config)#interface pos 1/0 
   RTR12410-1(config-if)#pos delay triggers ? 
  line  Specify delay for SONET LINE level triggers (S-LOS, S-LOF, L-AIS) 
  path  Enable SONET PATH level triggers (P-AIS, P-RDI), with optional delay 
RTR12410-1(config-if)#pos delay triggers line ? 
  <0-511>  Holdoff time, in msec 
  <cr>

Line- und Section-Trigger

Sie verwenden den PoS-Verzögerungsbefehl für Internet-Router-POS-Schnittstellen, die mit intern geschützten Dense Wavelength Division Multiplexing (DWDM)-Systemen verbunden sind (dokumentiert unter CSCdm36033 und CSCdp65436 auf Cisco Routern der Serie 1200 und CSCDr7 2941 für Cisco Router der Serien 7200 und 7500). Dieser Befehl ist ungültig für Schnittstellen, die als funktionierende oder geschützte APS konfiguriert sind. Normalerweise wird der Link selbst bei einigen Mikrosekunden von Alarmen auf Leitungs- oder Abschnittsebene (SLOS, SLOF oder LAIS) deaktiviert, bis der Alarm zehn Sekunden lang gelöscht wurde. Wenn Sie "holdoff" konfigurieren, wird dieser Link-Down-Trigger um 100 ms verzögert. Wenn der Alarm länger als 100 ms anhält, wird die Verbindung wie bisher deaktiviert. Wenn der Alarm vor 100 ms gelöscht wird, wird die Verbindung nicht deaktiviert.

Standardmäßig sind diese Zeilen- und Abschnittsalarme Auslöser für den Ausfall des Verbindungsprotokolls:

• Signalverlust

• Bildverlust

• Alarmsignal

Das Leitungsprotokoll der Schnittstelle fällt unverzüglich aus, wenn mindestens eine dieser Alarme geltend gemacht wird. Sie können den Befehl POS-Verzögerung auslösen, um den Ausfall des Leitungsprotokolls der Schnittstelle zu verhindern. Sie können die Verzögerung zwischen 0 und 511 ms einstellen. Wenn Sie kein Zeitintervall angeben, wird die Standardverzögerung auf 100 ms festgelegt.

Path-Level-Trigger

Diese Pfadalarme sind standardmäßig keine Trigger. Sie können diese Pfadalarme als Trigger konfigurieren und auch eine Verzögerung angeben:

• Wegweiser-Alarmsignal

• Anzeige von Fernfehlern für Pfad

• Zeigerverlust

Sie können den Befehl pos delay löst path aus, um verschiedene Pfadalarme als Trigger zu konfigurieren und um eine Aktivierungsverzögerung zwischen 0 und 511 ms anzugeben. Der Standardwert für die Verzögerung ist 100 ms.

Durch die PoS-Verzögerung wird die Pfadkonfiguration zum Herunterfahren des Leitungsprotokolls, wenn die höheren der B2- und B3-Fehlerraten mit dem SF-Schwellenwert (Signal Failure) verglichen werden. Wenn der SF-Grenzwert überschritten wird, wird das Leitungsprotokoll der Schnittstelle deaktiviert.

Der Befehl pos delay triggers path wurde in Version 12.0(16)S der Cisco IOS® Software eingeführt.

SONET-MIB

Cisco SONET-Schnittstellen unterstützen auch die SONET MIB, die in Request for Comments (RFC) 1595 definiert ist. Die RFC verwendet die gleiche Terminologie, um Fehlerzustände in einem SONET-Schaltkreis wie ANSI-Standards für SONET und in einem SDH-Schaltkreis (Synchronous Digital Hierarchy) durch die Spezifikation der International Telecommunications Union (ITU-T) G.783 zu beschreiben.

Informationen zur SONET MIB-Unterstützung für Cisco POS- und ATM over SONET-Schnittstellen finden Sie in den folgenden Ressourcen:

• Cisco MIBs: Listet die unterstützten MIBs pro Plattform sowie die Objekt-ID-Zeichenfolgen und die .my-Dateien für die SONET MIB auf.

• Cisco Serien 7000 und 12000 - Versionshinweise für Version 12.0 S - Beschreibt Verbesserungen der Cisco Unterstützung für die SONET MIB.

Zugehörige Informationen

• Support-Seiten für optische Hardware
• Support-Seiten für optische Technologie
• Technischer Support - Cisco Systems

Revisionsverlauf