Fehlerbehebung: T1 PPRI

Einleitung

In diesem Dokument wird beschrieben, wie Sie Fehler beheben und sicherstellen, dass eine Primary Rate Interface (PRI) T1 korrekt ausgeführt wird.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

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

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Konventionen

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

Hintergrundinformationen

Wenn Sie eine Fehlerbehebung für eine primäre Durchsatzschnittstelle (PRI) durchführen, stellen Sie sicher, dass der T1 auf beiden Seiten ordnungsgemäß ausgeführt wird. Der Grund hierfür ist, dass die ISDN PRI-Signalisierung auf der physischen T1-Ebene verwendet wird. Verwenden Sie den Befehl show controller t1, um zu überprüfen, ob T1 Layer 1 ordnungsgemäß ausgeführt wird. Stellen Sie sicher, dass auf keinem der Zähler Fehler vorhanden sind. Stellen Sie sicher, dass Framing, Zeilencodierung und Taktquelle richtig konfiguriert sind. Weitere Informationen finden Sie im Flussdiagramm zur Fehlerbehebung bei T1. Wenden Sie sich an Ihren Dienstanbieter, um die richtigen Einstellungen zu erhalten.

Wenn Sie Probleme in Layer 1 behoben haben und die t1-Zähler des Anzeigecontrollers Null sind, können Sie sich auf die Layer 2 und 3 der ISDN PRI-Signalisierung konzentrieren.

Tipp: Sie können den Befehl clear counters verwenden, um die T1-Zähler zurückzusetzen. Wenn die Zähler leer sind, können Sie leicht feststellen, ob auf der T1-Leitung Fehler auftreten. Denken Sie jedoch daran, dass dieser Befehl auch alle anderen Zähler für die Anzeigeoberfläche löscht. Hier ein Beispiel:

maui-nas-03#clear counters
Clear "show interface" counters on all interfaces [confirm]
maui-nas-03#
*Apr 12 03:34:12.143: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console

Verwenden des Befehls show isdn status

Der Befehl show isdn status ist sehr nützlich, um Probleme mit der ISDN-Signalisierung zu beheben. Der Befehl show isdn status zeigt eine Zusammenfassung des aktuellen Status aller ISDN-Schnittstellen sowie den Status der Layer 1, 2 und 3 an. Hier ist ein Beispiel für die Ausgabe des Befehls show isdn status:

maui-nas-03#show isdn status
Global ISDN Switchtype = primary-5ess
ISDN Serial0:23 interface
        dsl 0, interface ISDN Switchtype = primary-5ess
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        5 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 5
        CCB:callid=7D5, sapi=0, ces=0, B-chan=9, calltype=DATA
        CCB:callid=7D6, sapi=0, ces=0, B-chan=10, calltype=DATA
        CCB:callid=7DA, sapi=0, ces=0, B-chan=11, calltype=DATA
        CCB:callid=7DE, sapi=0, ces=0, B-chan=1, calltype=DATA
        CCB:callid=7DF, sapi=0, ces=0, B-chan=2, calltype=DATA
    The Free Channel Mask:  0x807FF8FC
ISDN Serial1:23 interface
        dsl 1, interface ISDN Switchtype = primary-5ess
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Activated dsl 1 CCBs = 0
    The Free Channel Mask:  0x807FFFFF
    Total Allocated ISDN CCBs = 5

Führen Sie die folgenden Schritte aus, um den Status der Ebenen zu überprüfen:

1. Überprüfen Sie, ob sich Layer 1 im Status AKTIV befindet. Der Status von Layer 1 muss immer "AKTIV" sein, es sei denn, T1 ist ausgefallen.

   Wenn der Befehl show isdn status anzeigt, dass Layer 1 DEACTIVATED ist, liegt ein Problem mit der physischen Verbindung der T1-Leitung vor. Wenn die Leitung administrativ ausgefallen ist, starten Sie die Schnittstelle mit dem Befehl no shutdown neu.

2. Stellen Sie sicher, dass sich Layer 2 im Status MULTIPLE_FRAME_ESTABLISHED befindet. Dies ist der erforderliche Status für Layer 2. Dieser Status gibt an, dass der Router eine ISDN-SABME-Nachricht (Set Asynchronous Balanced Mode Extended) empfangen und mit einem UA-Frame (Unnumbered Acknowledge) zur Synchronisierung mit dem Telco-Switch geantwortet hat. Außerdem müssen zwischen den beiden Geräten ständig Layer-2-Frames (Receiver Ready, RR) ausgetauscht werden. In diesem Fall haben der Router und der ISDN-Switch das ISDN-Layer-2-Protokoll vollständig initialisiert. Informationen zum Identifizieren der SABME- und RR-Meldungen finden Sie im Abschnitt Verwenden des Befehls debug q921.

   Wenn sich Layer 2 nicht im Status MULTIPLE_FRAME_ESTABLISHED befindet, verwenden Sie den Befehl debug isdn q921, um das Problem zu diagnostizieren.

   Darüber hinaus zeigt der Befehl show isdn status eine Zusammenfassung des aktuellen Status an. Daher kann Layer 2 auf- und abspringen, obwohl es den Status MULTIPLE_FRAME_ESTABLISHED anzeigt. Verwenden Sie den Befehl debug isdn q921, um sicherzustellen, dass Layer 2 stabil ist.

   Verwenden Sie zu diesem Zeitpunkt den Befehl show controller t1, um T1 erneut zu überprüfen und sicherzustellen, dass keine Fehler vorliegen. Wenn Fehler vorliegen, finden Sie weitere Informationen im T1-Fehlerbehebungs-Flussdiagramm.

   Im Beispiel show isdn status output, beachten Sie, dass T1 0 (dessen D-Kanal ist Serial 0:23) Layer 1 als AKTIV und Layer 2 als MULTIPLE_FRAME_ESTABLISHED hat, um anzuzeigen, dass der Signalisierungskanal korrekt funktioniert und Layer 2-Frames mit dem Telco-Switch austauscht. Der D-Kanal (Serial1:23) für T1 1 verfügt über Layer 1 ACTIVE, Layer 2 ist jedoch TEI_ASSIGNED, was darauf hinweist, dass der PRI keine Layer-2-Frames mit dem Switch austauscht. Verwenden Sie den Befehl show controller t1 xvor, um zunächst die T1-Schaltung des Controllers zu überprüfen und zu überprüfen, ob dieser sauber ist (d. h. keine Fehler aufweist), bevor Sie das ISDN Layer 2-Problem mit dem debug isdn q921 beheben. Weitere Informationen finden Sie im T1 Troubleshooting Flow Chart.

Verwenden des Befehls debug isdn q921

Dieser Debug-Befehl ist hilfreich, wenn Sie Probleme mit ISDN Layer 2-Signalisierung beheben möchten. Der Befehl debug isdn q921 zeigt Zugriffsverfahren für die Sicherungsschicht (Layer 2) an, die beim Router auf dem D-Kanal auftreten. Dies kann anzeigen, ob das Problem beim NAS, dem Telco-Switch oder der Leitung liegt.

Verwenden Sie den Befehl logging console or terminal monitor, um sicherzustellen, dass Sie für die Anzeige von Debugmeldungen konfiguriert sind.

Hinweis: Verwenden Sie in einer Produktionsumgebung den Befehl show logging, um sicherzustellen, dass die Konsolenprotokollierung deaktiviert ist. Wenn die Protokollierungskonsole aktiviert ist, kann der Zugriffsserver seine Funktionen gelegentlich beenden, wenn der Konsolenport mit Protokollmeldungen überlastet ist. Geben Sie den Befehl no logging console ein, um die Protokollierung am Konsolenport zu deaktivieren. Weitere Informationen finden Sie unter Wichtige Informationen zu Debugbefehlen.

Hinweis: Wenn debug isdn q921 aktiviert ist und Sie keine Debug-Ausgaben erhalten, überprüfen Sie zuerst, ob Sie Terminalmonitor aktiviert haben. Versuchen Sie dann, den Controller oder den D-Kanal zurückzusetzen, um Debug-Ausgaben zu erhalten. Sie können den Befehl clear controller t1 oder clear interface serial x:23 verwenden, um die Zeile zurückzusetzen.

Gehen Sie wie folgt vor, um sicherzustellen, dass die Zugriffsverfahren auf der Sicherungsschicht beim Router auf dem D-Kanal erfolgen:

1. Überprüfen der Stabilität von Layer 2 Suchen Sie dazu in der Debugausgabe nach Meldungen. Hier ist die Ausgabe von debug isdn q921, wenn der T1-Controller ein Herunterfahren und kein Herunterfahren durchläuft:

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, 
   TEI 0 changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:23, 
   changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: 
   Controller 0 clock is now selected as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, 
   TEI 0 changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, 
   changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:23, 
   changed state to up

   Wenn die Linie auf- und abspringt, wird eine ähnliche Ausgabe angezeigt:

   %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
   %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed to up
   %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
   %LINK-3-UPDOWN: Interface Serial0:23, changed state to down

2. Wenn Layer 2 stabil ist, müssen Router und Switch mit der Synchronisierung beginnen. Die Meldung Set Asynchronous Balanced Mode Extended (SABME) (Asynchroner Balanced-Modus festlegen) wird auf dem Display angezeigt. Diese Meldung zeigt an, dass Layer 2 versucht, mit der anderen Seite zu initialisieren. Beide Seiten können die Nachricht senden und versuchen, mit der anderen Seite zu initialisieren. Wenn der Router die SABME-Nachricht empfängt, muss er einen Unnumbered Acknowledge frame (UAf) zurücksenden. Der Router ändert dann den Layer-2-Status in MULTIPLE_FRAME_ESTABLISHED. Hier ein Beispiel:

   *Apr 12 04:14:43.967: ISDN Se0:23: RX <- SABMEp c/r=1 sapi=0 tei=0
   
   *Apr 12 04:14:43.971: ISDN Se0:23: TX -> UAf c/r=1 sapi=0 tei=0
   
   

   Wenn der Switch die UAf empfängt und erkennt, werden beide Geräte synchronisiert, und es werden regelmäßige Keepalives zwischen dem Router und dem ISDN-Switch ausgetauscht. Diese Meldungen sind als Receiver Ready (RRf und RRp). Diese Keepalives sind im Abstand von zehn Sekunden sichtbar und stellen sicher, dass beide Seiten miteinander kommunizieren können. Beispiele:

   *Apr 12 05:19:56.183: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
   
   *Apr 12 05:19:56.183: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
   *Apr 12 05:20:06.247: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
   
   *Apr 12 05:20:06.247: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
   *Apr 12 05:20:16.311: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
   
   *Apr 12 05:20:16.311: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
   
   

   Bitte beachten Sie die TX und RX und den Pfeil. TX gibt an, dass der Router das Signal zum Switch sendet. RX bedeutet, dass der Router das Signal vom Switch empfängt.

3. Manchmal wird der D-Kanal nicht richtig hochgefahren und bleibt im Zustand "TEI_ASSIGNED", oder Layer 2 springt auf und ab. Dies kann durch eine unidirektionale Übertragung oder verpasste Keepalive-Pakete verursacht werden. Wenn beide Seiten vier aufeinander folgende Keepalives übersehen, versucht die jeweilige Seite, die Layer-2-Verbindung erneut zu initialisieren. Um dies zu erreichen, sendet die Seite die SABME-Nachricht erneut und startet den Prozess erneut. In einer solchen Situation müssen Sie herausfinden, ob diese Keepalives tatsächlich auf dem Kabel platziert sind und ob eine Seite nicht auf die Keepalives reagiert, wenn sie sie empfängt.

   Um das Problem zu isolieren, verwenden Sie den Befehl debug isdn q921 und show interface serial x:23 commands, und führen Sie die folgenden Schritte auf dem Router und bei T1 Service Provider (Telco) aus:

   1. Führen Sie show interface serial x:23 mehrmals aus, und stellen Sie sicher, dass der Ausgabenzähler inkrementiert wird und es keine Eingabe-/Ausgabeverfügungen oder -fehler gibt.

   2. Erstellen Sie einen T1-Loopback-Stecker, und schließen Sie ihn an den T1-Port an, für den Sie eine Fehlerbehebung durchführen möchten. Die Ausgabe von debug isdn q921 muss angeben, dass das SABME gesendet wurde, und diese Nachricht wurde empfangen:

      RX <- BAD FRAME(0x00017F)Line may be looped!

      Wenn keine Debugging-Meldungen angezeigt werden, führen Sie ein Herunterfahren und kein Herunterfahren des entsprechenden T1-Controllers aus.

      Die BAD FRAME-Meldungen weisen darauf hin, dass der Router die richtige Leistung erbringt. Der Router sendet das SABME-Paket. Die Nachricht wird per Loopback an den Router gesendet, sodass dieser dieselbe SABME-Nachricht erhält, die gesendet wurde. Der Router markiert den Frame als BAD FRAME und zeigt die Fehlermeldung an. In der Fehlermeldung wird angegeben, dass die Leitung wahrscheinlich eine Schleife aufweist. Dies ist das erwartete Verhalten für den Looped Circuit. Das Problem liegt daher beim Telco ISDN Switch bzw. bei der Verkabelung von der Demarkasse zum Telco Switch.

      Wenn die Leitung jedoch zurückgeschleift wird und der Router SABMEs sendet, diese aber nicht wieder empfängt, kann es zu Problemen mit dem physischen Loopback-Kabelstecker oder der Router-Schnittstelle selbst kommen. Überprüfen Sie anhand der Loopback-Tests für T1/56K-Leitungen, ob Sie den Router vom gleichen Router aus mithilfe des Loopback-Tests für die Hardwire-Leitung pingen können. Wenn Sie den Router nicht pingen können, liegt möglicherweise ein Hardwareproblem mit dem T1-Controller vor. In diesem Fall wenden Sie sich an das TAC. Wenn Sie den Router pingen können, fahren Sie mit Schritt c fort.

   3. Nachdem Sie den Router und die T1-Ports isoliert und getestet und deren Funktionstüchtigkeit bestätigt haben, müssen Sie sich an die Telco wenden, um eine weitere Fehlerbehebung durchzuführen.

      • Wenden Sie sich an die Telco, und fragen Sie nach, warum der Switch nicht auf den Keepalive reagiert. Lassen Sie die Telco-Funktion überprüfen, um festzustellen, ob die Keepalive-Nachrichten oder alle eingehenden ISDN Layer 2-Nachrichten vom Router angezeigt werden.

      • Führen Sie den Loopback-Test erneut durch, erweitern Sie den Loopback-Test diesmal jedoch auf den Telco-Switch. Dieses Verfahren wird im Artikel "Loopback Tests for T1/56K Lines" beschrieben.

      • Bitten Sie den Techniker des Telco-Switches, eine Schleife in der Leitung zu platzieren, und testen Sie dann, ob der Router weiterhin sich selbst pingen kann.

      • Wenn der Router keinen eigenen Ping-Befehl senden kann, kann es zu Problemen mit der Verkabelung des Stromkreises zum Telco-ISDN-Switch kommen. Weitere Informationen finden Sie unter Loopback-Tests für T1/56K-Leitungen.

      • Wenn der Router sich selbst pingen kann, ist der Loopback-Test erfolgreich. Machen Sie die Loopback-Konfiguration rückgängig, und ändern Sie die Controller-Konfiguration von Channel-Gruppe zu Pro-Gruppe .

        maui-nas-03(config)#controller t1 0
        maui-nas-0(config-controller)#no channel-group 0
        maui-nas-0(config-controller)#pri-group timeslots 1-24
        

      • Führen Sie einen Shutdown und kein Herunterfahren des Controllers durch, und überprüfen Sie, ob der Router dies sendet:

        ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0

        und erhält Folgendes:

        RX <- BAD FRAME(0x00017F)Line may be looped!

        In diesem Fall funktioniert der Router ordnungsgemäß, und der Übertragungs- und Empfangspfad zur Telco-Lösung funktioniert einwandfrei. Das Problem liegt im ISDN-Switch oder im ISDN-Netzwerk. Wenn der Router jedoch Folgendes sendet:

        ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0

        und erhält diese nicht:

        RX <- BAD FRAME(0x00017F)Line may be looped!

        Weitere Unterstützung erhalten Sie vom TAC-Support.

Fehlerbehebung bei ISDN Layer 3

Wenn Sie alle mit dem PRI verbundenen Layer-2-Probleme beheben und sicherstellen, dass die Hardware einwandfrei funktioniert, müssen Sie eine Fehlerbehebung für ISDN Layer 3 durchführen. Weitere Informationen finden Sie unter Problembehandlung bei ISDN BRI Layer 3 mit dem Befehl debug isdn q931.

Hinweis: Auch wenn im Dokument die Layer-3-Fehlerbehebung für BRIs behandelt wird, können Sie dieselben Konzepte auf die Layer-3-PRI-Fehlerbehebung anwenden. Sie können auch unter Debugging verstehen (ISDN q931) den Grund für die Trennung von Layer 3 interpretieren.

Zugehörige Informationen

• T1-Alarm-Fehlerbehebung
• Loopback-Tests für T1/56K-Leitungen
• T1 Fehlerereignisse Fehlerbehebung
• Technischer Support und Downloads von Cisco