Fehlerbehebung bei Anruftechnik - IOS DDR initiiert Anruf

Einführung

Dieses Dokument enthält Methoden zur Fehlerbehebung für verschiedene Arten von Wählverbindungen. Es ist nicht für den Einstieg in die Endfassung vorgesehen. Die Struktur ist so konzipiert, dass der Leser die Bereiche, die von Interesse sind, überspringen kann, die jeweils Variationen des allgemeinen Design für die Fehlerbehebung für einen bestimmten Fall.

Voraussetzungen

Anforderungen

In diesem Dokument werden drei Hauptszenarien behandelt: Bevor Sie mit der Fehlerbehebung beginnen, ermitteln Sie, welche Art von Anruf versucht wird, und gehen Sie zu diesem Abschnitt:

• Callin

• Cisco IOS-DDR (Dial-on-Demand Routing)

• Nicht-DDR-Callout

Verwendete Komponenten

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

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Geschichte

Dialup ist einfach die Anwendung des öffentlichen Telefonnetzes (PSTN), das Daten für den Endbenutzer überträgt. Dazu gehört ein Gerät am Kundenstandort (Customer Premises Equipment, CPE), das dem Telefon-Switch eine Telefonnummer sendet, an die eine Verbindung geleitet werden soll. Die Router AS3600, AS5200, AS5300 und AS5800 sind alle Beispiele für Router, die zusammen mit den Banken digitaler Modems eine Primär-Rate-Schnittstelle (PRI) betreiben können. Das AS2511 dagegen ist ein Beispiel für einen Router, der mit externen Modems kommuniziert.

Der Carrier-Markt ist stark gewachsen, und der Markt verlangt jetzt höhere Modemdichten. Die Antwort auf diese Notwendigkeit ist eine stärkere Zusammenarbeit mit der Telefonanlage und die Entwicklung des digitalen Modems. Dies ist ein Modem, das direkten digitalen Zugriff auf das PSTN ermöglicht. Infolgedessen wurden schnellere CPE-Modems entwickelt, die das klare Signal nutzen, das digitale Modems genießen. Die Tatsache, dass die digitalen Modems, die über eine PRI- oder BRI-Schnittstelle (Basic Rate Interface) mit dem PSTN verbunden sind, Daten über 53.000 unter Verwendung des V.90-Kommunikationsstandards übertragen können, bestätigt den Erfolg der Idee.

Die ersten Zugriffsserver waren AS2509 und AS2511. Das AS2509 könnte mithilfe externer Modems 8 eingehende Verbindungen unterstützen, das AS2511 könnte 16 unterstützen. Das AS5200 wurde mit zwei PRIs eingeführt und konnte 48 Benutzer mit digitalen Modems unterstützen. Es war ein bedeutender Sprung nach vorn in der Technologie. Die Modemdichten wurden mit Unterstützung von 4 und 8 PRIs beim AS5300 stetig erhöht. Schließlich wurde das AS5800 eingeführt, um die Anforderungen von Installationen der Carrier-Klasse zu erfüllen, die Dutzende von eingehenden T1- und Hunderten von Benutzerverbindungen handhaben müssen.

Einige veraltete Technologien lassen sich in einer historischen Diskussion über Dialer-Technologie erwähnen. 56Kflex ist ein älterer (vor V.90) 56k Modemstandard, der von Rockwell vorgeschlagen wurde. Cisco unterstützt Version 1.1 des 56Kflex-Standards auf seinen internen Modems, empfiehlt jedoch, die CPE-Modems so bald wie möglich auf V.90 zu migrieren. Eine weitere veraltete Technologie ist das AS5100. Das AS5100 war ein Joint Venture zwischen Cisco und einem Modemhersteller. Das AS5100 wurde als Möglichkeit entwickelt, die Modemdichte durch Verwendung von Quad-Modemkarten zu erhöhen. Es umfasste eine Gruppe von AS2511-Karten, die als Karten erstellt wurden und in eine Rückwandplatine integriert wurden, die von Quad-Modemkarten gemeinsam genutzt wurde, sowie eine duale T1-Karte.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Cisco IOS DDR initiiert Anruf

Während der Fehlerbehebungsansatz für eingehende Anrufe unten beginnt, beginnt die Fehlerbehebung für ausgehende Verbindungen oben.

Der allgemeine Ablauf der Argumentation ähnelt dem folgenden:

1. Lässt sich ein Anruf über das DFÜ-Routing (Dial on Demand Routing, DDR) initiieren? (Eine Ja-Antwort bringt uns zur nächsten Frage.)

2. Wenn es sich um ein asynchrones Modem handelt, stellen die Chat-Skripte die erwarteten Befehle aus?

3. Macht der Anruf es zum PSTN?

4. Wird der Anruf vom Remote-Ende angenommen?

5. Wird der Anruf beendet?

6. Werden Daten über den Link übertragen?

7. Ist die Sitzung eingerichtet? (PPP oder Terminal)

Um zu sehen, ob der Dialer versucht, einen Anruf an sein Remote-Ziel zu tätigen, verwenden Sie den Befehl debug dialer events. Detailliertere Informationen können aus dem Debug-Dialer-Paket gewonnen werden, aber der Debug-Dialer-Paket-Befehl ist ressourcenintensiv und sollte nicht auf einem belebten System mit mehreren Dialer-Schnittstellen verwendet werden.

In der folgenden Zeile der Debug Dialer-Ereignisausgabe für ein IP-Paket sind der Name der DDR-Schnittstelle und die Quell- und Zieladresse des Pakets aufgeführt:

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

Wenn der Datenverkehr keinen Wählversuch auslöst, ist der häufigste Grund eine fehlerhafte Konfiguration (entweder eine der interessanten Verkehrsdefinitionen, der Zustand der Dialer-Schnittstelle oder die Routing-Klasse).

Tätigen eines Anrufs

Wenn die Routing- und die interessanten Datenverkehrsfilter korrekt sind, sollte ein Anruf initiiert werden. Dies wird durch die Verwendung von Debug Dialer-Ereignissen angezeigt:

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

Wenn die Wählursache angezeigt wird, aber kein Wählversuch unternommen wird, ist der übliche Grund eine falsch konfigurierte Wählzuordnung oder ein falsch konfiguriertes Wählprofil.

Dialer1: Can't place call, no dialer pool set

Identifizieren Sie anschließend den verwendeten Medientyp:

• DDR für externes asynchrones Modem

• Channel Associated Signaling (CAS) T1/E1 async-Modem DDR

• PRI async-Modem DDR

• BRI-async-Modem-DDR

• PRI ISDN DDR

• BRI ISDN DDR

Externes Async-Modem DDR

1. Um ein externes asynchrones Modem-DDR zu identifizieren, verwenden Sie die folgenden Befehle, und versuchen Sie dann, einen Anruf zu tätigen:

   router# debug modem
   router# debug chat line  
            
   
   

2. Bei Modemanrufen muss ein Chat-Skript ausgeführt werden, damit der Anruf fortgesetzt werden kann. Bei einem DDR, der auf einer Dialerzuordnung basiert, wird das Chat-Skript vom Modem-Script-Parameter in einem Dialer-Map-Befehl aufgerufen. Wenn der DDR auf einem Dialer-Profil basiert, wird dies über den in der TTY-Leitung konfigurierten Befehlsskripdialer erreicht. Beide Methoden basieren auf einem in der globalen Konfiguration des Routers vorhandenen Chat-Skript, z. B.:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   In beiden Fällen lautet der Befehl zum Anzeigen der Chat-Skriptaktivität Debug-Chat. Wenn die Wählzeichenfolge (d. h. die Telefonnummer), die im Befehl Dialer Map oder Dialer String verwendet wird, 5551212 lautete, würde die Debug-Ausgabe wie folgt aussehen:

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Stellen Sie sicher, dass das Chat-Skript den erwarteten Anruf (d. h. die richtige Nummer) basierend auf der "Sending String" (Sendezeichenfolge) versucht. Wenn das Chat-Skript nicht versucht, den erwarteten Anruf zu tätigen, überprüfen Sie die Konfiguration des Chat-Skripts. Verwenden Sie den Start-Chat-Befehl an der exec-Eingabeaufforderung, um das Chat-Skript manuell zu starten.

4. Anzeige von "Timeout Expecting: CONNECT" beschreibt mehrere Möglichkeiten:

   • Möglichkeit 1: Das lokale Modem führt den Anruf nicht aus. Stellen Sie sicher, dass das Modem einen Anruf tätigen kann, indem es ein umgekehrtes Telnet zum Modem durchführt und manuell eine Rufnummer initiiert. Wenn das Remote-Ende anscheinend nicht antwortet, stellen Sie sicher, dass der Anruf vom ursprünglichen Modem getätigt wird. Rufen Sie dazu manuell eine lokale Nummer mit dem Befehl ATDT <number> an, und hören Sie auf den Klingelton zu.

   • Möglichkeit 2: Das Remote-Modem antwortet nicht. Testen Sie dies, indem Sie das Remote-Modem mit einem normalen POTS-Telefon wählen. Versuchen Sie es:

     1. Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen. Stellen Sie sicher, dass Sie dasselbe Kabel an der Steckdose verwenden, die das Modem verwendet hat. Wenn ein manueller Anruf das empfangende async-Modem erreichen kann, funktioniert das ursprüngliche Modem möglicherweise nicht ordnungsgemäß. Überprüfen Sie das Modem, und ersetzen Sie es bei Bedarf.

     2. Wenn ein manueller Anruf das beantwortende asynchrone Modem nicht erreichen kann, wechseln Sie die Telefonkabel des Empfangsmodems, und versuchen Sie, ein normales Telefon an der Leitung des empfangenden Modems zu verwenden. Wenn der Anruf vom regulären Telefon empfangen werden kann, besteht wahrscheinlich ein Problem mit dem empfangenden Modem.

     3. Wenn der manuelle Anruf auf der betreffenden Leitung immer noch nicht am regulären Telefon ankommt, versuchen Sie es mit einer anderen (zweifelsfrei funktionierenden) Leitung in der Empfangseinrichtung. Wenn die Verbindung OK ist, lassen Sie das Telefon vom Fernsprecher überprüfen, ob die Telefonleitung zum Empfangsmodem geleitet wird.

     4. Wenn es sich um ein Ferngespräch handelt, lassen Sie die Anruferseite eine andere (zweifelsfrei funktionierende) Fernnetznummer ausprobieren. Wenn dies funktioniert, kann die Empfangsanlage oder -leitung nicht für Ferngespräche bereitgestellt werden. Wenn die Ausgangsleitung keine anderen Ferngesprächsnummern erreichen kann, ist möglicherweise die Option für Ferngespräche nicht aktiviert. Testen Sie 1010-Codes für verschiedene Fernanbieter.

     5. Versuchen Sie abschließend eine andere (zweifelsfrei funktionierende) lokale Nummer aus der Ausgangsleitung. Wenn die Verbindung immer noch fehlschlägt, lassen Sie das telco-Gerät die ursprüngliche Leitung überprüfen.

   • Möglichkeit 3: Die gewählte Nummer ist falsch. Überprüfen Sie die Nummer, indem Sie sie manuell wählen. Korrigieren Sie ggf. die Konfiguration.

   • Möglichkeit 4: Die Modemschulung dauert zu lange oder der TIMEOUT-Wert ist zu niedrig. Versuchen Sie, den TIMEOUT-Wert im Chat-Script-Befehl zu erhöhen. Wenn der TIMEOUT bereits 60 Sekunden oder länger ist, besteht möglicherweise ein Kabelproblem zwischen dem Modem und der DTE, an die er angeschlossen ist. Ausübungsfehler können auch auf ein Schaltungsproblem oder eine Modeminkompatibilität hinweisen.

     Um ein einzelnes Modemproblem zu beheben, gehen Sie zur AT-Eingabeaufforderung am ursprünglichen Modem mit Reverse Telnet. Wenn möglich, rufen Sie auch die AT-Eingabeaufforderung des empfangenden Modems auf. Die meisten Modems weisen auf einen Klingelton für die Terminalsitzung hin, die an ihre DTE-Verbindung angeschlossen ist. Verwenden Sie ATM1, damit das Modem Töne an seinen Sprecher sendet, damit die Teilnehmer an jedem Ende hören können, was in der Leitung geschieht.

     Gibt es in der Musik ein Geräusch? Wenn ja, säubern Sie den Stromkreis. Wenn die Async-Modems nicht trainieren, rufen Sie die Nummer an, und achten Sie auf Statisch. Es können weitere Faktoren auftreten, die den Zugbetrieb beeinflussen. Umleiten von Telnet zum asynchronen Modem und Debuggen

5. Wenn alles gut funktioniert und Sie immer noch keine Verbindung mit dem CAS-Async-Modem-DDR herstellen können, versuchen Sie es mit PPP-Debuggen. Verwenden Sie die Befehle:

   router# debug ppp negotiation
        router# debug ppp authentication
   

   Wenn das Chat-Skript erfolgreich abgeschlossen wurde, sind die Modems verbunden. Im Abschnitt "Fehlerbehebung bei PPP" in Kapitel 17 des Leitfadens zur Internetwork-Fehlerbehebung erfahren Sie, wie Sie bei der Behebung von Verbindungsproblemen weiter vorgehen können.

CAS T1/E1 Async-Modem DDR

1. Um ein asynchrones CAS T1/E1-Modem-DDR zu identifizieren, verwenden Sie die folgenden Befehle und versuchen Sie dann, einen Anruf zu tätigen:

   Warnung:  Wenn auf einem ausgelasteten System Debug ausgeführt wird, kann der Router abstürzen, indem die CPU überlastet oder der Konsolenpuffer überlastet wird!

   router# debug modem
   router# debug chat or debug chat line n
   
   router# debug modem csm
   router# debug cas
   

   Hinweis: Der Befehl debug cas ist auf Cisco AS5200- und AS5300-Plattformen mit Cisco IOS verfügbar? Softwareversion 12.0(7)T und höher In früheren Versionen von IOS muss der interne Befehlsdienst in die Hauptebene der Konfiguration des Routers eingegeben werden, und Modem-mgmt csm debug-rbs muss an der exec-Eingabeaufforderung eingegeben werden. Beim Debuggen auf dem Cisco AS5800 muss eine Verbindung zur Trunk Card hergestellt werden. (Verwenden Sie modem-mgmt csm no-debug-rbs, um den Debugger auszuschalten.)

2. Bei Modemanrufen muss ein Chat-Skript ausgeführt werden, damit der Anruf fortgesetzt werden kann. Bei einem DDR, der auf einer Dialerzuordnung basiert, wird das Chat-Skript vom Modem-Script-Parameter in einem Dialer-Map-Befehl aufgerufen. Wenn der DDR auf einem Dialer-Profil basiert, wird dies über den in der TTY-Leitung konfigurierten Befehlsskripdialer erreicht. Beide Anwendungen basieren auf einem in der globalen Konfiguration des Routers vorhandenen Chat-Skript, z. B.:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   In beiden Fällen lautet der Befehl zum Anzeigen der Chat-Skriptaktivität Debug-Chat. Wenn die Wählzeichenfolge (d. h. die Telefonnummer), die im Befehl Dialer Map oder Dialer String verwendet wird, 5551212 lautete, würde die Debug-Ausgabe wie folgt aussehen:

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Stellen Sie sicher, dass das Chat-Skript den erwarteten Anruf (d. h. die richtige Nummer) basierend auf der "Sending String" versucht. Wenn das Chat-Skript nicht versucht, den erwarteten Anruf zu tätigen, überprüfen Sie die Konfiguration des Chat-Skripts. Verwenden Sie den Start-Chat-Befehl an der exec-Eingabeaufforderung, um das Chat-Skript manuell zu starten.

4. Anzeige von "Timeout Expecting: CONNECT" beschreibt mehrere Möglichkeiten:

   • Möglichkeit 1: Das lokale Modem führt den Anruf nicht aus. Stellen Sie sicher, dass das Modem einen Anruf tätigen kann, indem es ein umgekehrtes Telnet zum Modem durchführt und manuell eine Rufnummer initiiert. Wenn das Remote-Ende anscheinend nicht antwortet, stellen Sie sicher, dass der Anruf vom Modem getätigt wird, indem Sie eine lokale Nummer manuell mit dem Befehl ATDT<number> anrufen und den Klingelton hören.

     Bei ausgehenden Anrufen über CAS T1 oder E1 und integrierte digitale Modems ähnelt ein Großteil der Fehlerbehebung anderen DDR-Fehlerbehebungen. Gleiches gilt auch für ausgehende integrierte Modemanrufe über eine PRI-Leitung. Die einzigartigen Funktionen, die bei einem solchen Anruf auftreten, erfordern ein spezielles Debuggen im Falle eines Anruffehlers.

     Wie bei anderen DDR-Situationen müssen Sie sicherstellen, dass ein Anruf angefordert wird. Verwenden Sie zu diesem Zweck Debug-Dialer-Ereignisse. Siehe IOS DDR, weiter oben in diesem Artikel.

     Bevor ein Anruf getätigt werden kann, muss dem Anruf ein Modem zugewiesen werden. Um diesen Prozess und den nachfolgenden Aufruf anzuzeigen, verwenden Sie die folgenden Debugbefehle:

     router# debug modem
     router# debug modem csm
     router# debug cas 
     

     Hinweis: Der Befehl debug cas wurde zuerst in IOS Version 12.0(7)T für AS5200 und AS5300 angezeigt. Ältere Versionen von IOS verwenden einen internen Konfigurationsbefehlsdienst auf Systemebene zusammen mit dem Exec-Befehl modem-mgmt debug rbs:

     Aktivieren von Debuggen:

     router#conf t 
     Enter configuration commands, one per line.  End with CNTL/Z. 
     router(config)#service internal 
     router(config)#^Z 
     router#modem-mgmt csm ? 
       debug-rbs     enable rbs debugging 
       no-debug-rbs  disable rbs debugging 
     router#modem-mgmt csm debug-rbs 
     router# 
     neat msg at slot 0: debug-rbs is on 
     neat msg at slot 0: special debug-rbs is on 
     

     Ausschalten des Debuggers:

     router#modem-mgmt csm no-debug-rbs 
     neat msg at slot 0: debug-rbs is off 

     Beim Debuggen dieser Informationen auf einem AS5800 muss eine Verbindung zur Trunk Card hergestellt werden. Im Folgenden sehen Sie ein Beispiel für einen normalen ausgehenden Anruf über einen CAS T1, der für FXS-Ground-Start bereitgestellt und konfiguriert wird:

     Mica Modem(1/0): Rcvd Dial String(5551111) 
     [Modem receives digits from chat script]
     
     CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_LOCK at slot 1 and port 0 
     
     CSM_PROC_OC4_DIALING: 
     CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
     
     Mica Modem(1/0): Configure(0x1) 
     
     Mica Modem(1/0): Configure(0x2) 
     
     Mica Modem(1/0): Configure(0x5) 
     
     Mica Modem(1/0): Call Setup 
     
     neat msg at slot 0: (0/2): Tx RING_GROUND 
     
     Mica Modem(1/0): State Transition to Call Setup 
     
     neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
     [Telco switch goes OFFHOOK]
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_START_TX_TONE at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 
     
     neat msg at slot 0: (0/2): 
     Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
     
     Mica Modem(1/0): Rcvd Tone detected(2) 
     
     Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
     
     Mica Modem(1/0): Rcvd Digits Generated 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_CONNECTED at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 
     
     Mica Modem(1/0): Link Initiate 
     
     Mica Modem(1/0): State Transition to Connect 
     
     Mica Modem(1/0): State Transition to Link 
     
     Mica Modem(1/0): State Transition to Trainup 
     
     Mica Modem(1/0): State Transition to EC Negotiating 
     
     Mica Modem(1/0): State Transition to Steady State 
     
     Mica Modem(1/0): State Transition to Steady State Speedshifting 
     
     Mica Modem(1/0): State Transition to Steady State
     

     Debugger für T1s und E1s mit anderen Signalisierungstypen sind ähnlich.

     Wenn Sie diesen Punkt beim Debuggen erreichen, wird angezeigt, dass die aufrufenden und antwortenden Modems geschult und verbunden wurden und dass die Protokolle höherer Ebenen mit Verhandlungen beginnen können. Wenn ein Modem ordnungsgemäß für den ausgehenden Anruf reserviert ist, die Verbindung jedoch nicht so weit kommt, muss die T1-Verbindung überprüft werden. Verwenden Sie den Befehl show controller t1/e1, um zu überprüfen, ob T1/E1 funktioniert. Unter Fehlerbehebung bei seriellen Posten finden Sie eine Erläuterung der Ausgabe des Anzeigecontrollers. Wenn T1/E1 nicht ordnungsgemäß funktioniert, ist die T1/E1-Fehlerbehebung erforderlich.

   • Möglichkeit 2: Das Remote-Modem antwortet nicht. Testen Sie dies, indem Sie das Remote-Modem mit einem normalen Telefon wählen. Versuchen Sie es:

     1. Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen.

     2. Stellen Sie sicher, dass ein manueller Anruf das beantwortende async-Modem erreichen kann. Wenn ein manueller Anruf das beantwortende async-Modem erreichen kann, wird die CAS-Leitung möglicherweise nicht für ausgehende Sprachanrufe bereitgestellt.

     3. Wenn ein manueller Anruf das beantwortende asynchrone Modem nicht erreichen kann, wechseln Sie die Telefonkabel des Empfangsmodems, und versuchen Sie, ein normales Telefon an der Leitung des empfangenden Modems zu verwenden. Wenn der Anruf vom regulären Telefon empfangen werden kann, besteht wahrscheinlich ein Problem mit dem empfangenden Modem.

     4. Wenn der manuelle Anruf auf der betreffenden Leitung immer noch nicht am regulären Telefon ankommt, versuchen Sie es mit einer anderen (zweifelsfrei funktionierenden) Leitung in der Empfangseinrichtung. Wenn diese Verbindung hergestellt wird, lassen Sie das Telefon vom Fernsprecher überprüfen, ob die Telefonleitung zum Empfangsmodem geleitet wird.

     5. Wenn es sich um ein Ferngespräch handelt, lassen Sie die Anruferseite eine andere (zweifelsfrei funktionierende) Fernnetznummer ausprobieren. Wenn dies funktioniert, kann die Empfangsanlage oder -leitung nicht für Ferngespräche bereitgestellt werden. Wenn die Ausgangsleitung (CAS) keine anderen Nummern für Ferngespräche erreichen kann, ist die Fernleitung möglicherweise nicht aktiviert. Testen Sie 10-10 Codes für verschiedene Fernanbieter.

     6. Versuchen Sie schließlich eine andere (zweifelsfrei funktionierende) lokale Nummer aus der ursprünglichen CAS-Leitung. Wenn die Verbindung immer noch fehlschlägt, lassen Sie den CAS durch telco überprüfen.

   • Möglichkeit 3: Die gewählte Nummer ist falsch. Überprüfen Sie die Nummer, indem Sie sie manuell wählen. Korrigieren Sie ggf. die Konfiguration.

   • Möglichkeit 4: Die Modemschulung dauert zu lange, oder der TIMEOUT-Wert ist zu niedrig. Versuchen Sie, den TIMEOUT-Wert im Chat-Script-Befehl zu erhöhen. Wenn der TIMEOUT bereits 60 Sekunden oder länger ist, besteht möglicherweise ein Kabelproblem zwischen dem Modem und der DTE, an die er angeschlossen ist. Ausübungsfehler können auch auf ein Schaltungsproblem oder eine Modeminkompatibilität hinweisen.

     Um ein einzelnes Modemproblem zu beheben, gehen Sie zur AT-Eingabeaufforderung am ursprünglichen Modem mit Reverse Telnet. Verwenden Sie nach Möglichkeit das umgekehrte Telnet, um zur AT-Eingabeaufforderung des empfangenden Modems zu gelangen. Verwenden Sie ATM1, damit das Modem Töne an seinen Sprecher sendet, damit die Teilnehmer an jedem Ende hören können, was in der Leitung geschieht.

     Gibt es in der Musik ein Geräusch? Wenn ja, säubern Sie den Stromkreis. Wenn die Async-Modems nicht trainieren, rufen Sie die Nummer an, und achten Sie auf Statisch. Es können weitere Faktoren auftreten, die den Zugbetrieb beeinflussen. Umleiten von Telnet zum asynchronen Modem und Debuggen

5. Wenn alles gut funktioniert und Sie immer noch keine Verbindung mit dem CAS-Async-Modem-DDR herstellen können, versuchen Sie es mit PPP-Debuggen. Wenn das Chat-Skript erfolgreich abgeschlossen wurde und die PPP-Debugger einen Fehler anzeigen, lesen Sie den Abschnitt "Fehlerbehebung bei PPP" in Kapitel 17 des Internetwork Troubleshooting Guide.

PRI Async Modem DDR

1. Um ein asynchrones PRI-Modem-DDR zu identifizieren, verwenden Sie die folgenden Befehle, und versuchen Sie dann, einen Anruf zu tätigen:

   Warnung:  Wenn auf einem ausgelasteten System Debug ausgeführt wird, kann der Router abstürzen, indem die CPU überlastet oder der Konsolenpuffer überlastet wird!

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug isdn
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. Bei Modemanrufen muss ein Chat-Skript ausgeführt werden, damit der Anruf fortgesetzt werden kann. Bei einem DDR, der auf einer Dialerzuordnung basiert, wird das Chat-Skript vom Modem-Script-Parameter in einem Dialer-Map-Befehl aufgerufen. Wenn der DDR auf einem Dialer-Profil basiert, wird dies über den in der TTY-Leitung konfigurierten Befehlsskripdialer erreicht. Beide Methoden basieren auf einem in der globalen Konfiguration des Routers vorhandenen Chat-Skript, z. B.:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

   In beiden Fällen lautet der Befehl zum Anzeigen der Chat-Skriptaktivität Debug-Chat. Wenn der Wählzeichenfolge (Telefonnummer), der in der Wählerzuordnung oder dem Befehl Dialer-Zeichenfolge 551212 verwendet wird, würde die Debug-Ausgabe wie folgt aussehen:

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Stellen Sie sicher, dass das Chat-Skript den erwarteten Anruf (die richtige Nummer) basierend auf der "Sending String" versucht. Wenn das Chat-Skript nicht versucht, den erwarteten Anruf zu tätigen, überprüfen Sie die Konfiguration des Chat-Skripts. Verwenden Sie den Start-Chat-Befehl an der exec-Eingabeaufforderung, um das Chat-Skript manuell zu starten.

4. Anzeige von "Timeout Expecting: CONNECT" beschreibt mehrere Möglichkeiten:

   • Möglichkeit 1: Das lokale Modem führt den Anruf nicht aus. Stellen Sie sicher, dass das Modem einen Anruf tätigen kann, indem es ein umgekehrtes Telnet zum Modem durchführt und manuell eine Rufnummer initiiert. Wenn das Remote-Ende anscheinend nicht antwortet, stellen Sie sicher, dass der Anruf vom Modem getätigt wird, indem Sie eine lokale Nummer manuell mit dem Befehl ATDT<number> anrufen und auf den Klingelton hören. Wenn kein Anruf beendet wird, aktivieren Sie ISDN-Debug. Überprüfen Sie bei dem ersten Verdacht auf einen ISDN-Ausfall auf einem BRI immer den Ausgang vom show isdn status. Zu beachten ist vor allem, dass Layer 1 aktiv sein sollte und Layer 2 MULTIPLE_FRAME_ESTABLISHED sein sollte. Weitere Informationen zum Lesen dieser Ausgabe finden Sie im Internetwork Troubleshooting Guide Kapitel 16, "Interpreting Show ISDN Status" (ISDN-Status anzeigen) sowie in den entsprechenden Korrekturmaßnahmen.

     Für ausgehende ISDN-Anrufe sind debug isdn q931 und debug isdn event die besten Tools. Glücklicherweise ähnelt das Debuggen ausgehender Anrufe dem Debuggen eingehender Anrufe. Ein normaler erfolgreicher Anruf könnte wie folgt aussehen:

     *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
     

     Beachten Sie, dass die CONNECT-Nachricht der Schlüsselindikator für den Erfolg ist. Wenn keine CONNECT-Nachricht empfangen wird, wird möglicherweise eine DISCONNECT- oder eine RELEASE_COMP-Nachricht (Release Complete) angezeigt, gefolgt von einem Ursachencode:

     *Mar 20 22:11:03.212: ISDN SE0:23: 
     RX <-RELEASE_COMP pd = 8 callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     Der Ursachenwert weist auf zwei Dinge hin:

     • Das zweite Byte des 4- oder 6-Byte-Werts gibt den Punkt im End-to-End-Anrufpfad an, von dem der DISCONNECT oder RELEASE_COMP empfangen wurde. Dies kann Ihnen helfen, das Problem zu lokalisieren.

     • Das dritte und vierte Byte geben den tatsächlichen Grund für den Ausfall an. Die Bedeutung der verschiedenen Werte finden Sie in Tabelle 9.

   • Möglichkeit 2: Das Remote-Modem antwortet nicht. Testen Sie dies, indem Sie das Remote-Modem mit einem normalen Telefon wählen. Versuchen Sie es:

     1. Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen.

     2. Stellen Sie sicher, dass ein manueller Anruf das beantwortende async-Modem erreichen kann. Wenn ein manueller Anruf das beantwortende async-Modem erreichen kann, wird die BRI-Leitung möglicherweise nicht für ausgehende Sprachanrufe bereitgestellt.

     3. Wenn ein manueller Anruf das beantwortende asynchrone Modem nicht erreichen kann, wechseln Sie die Telefonkabel des Empfangsmodems, und versuchen Sie, ein normales Telefon an der Leitung des empfangenden Modems zu verwenden. Wenn der Anruf vom regulären Telefon empfangen werden kann, besteht wahrscheinlich ein Problem mit dem empfangenden Modem.

     4. Wenn der manuelle Anruf auf der betreffenden Leitung immer noch nicht am regulären Telefon ankommt, versuchen Sie es mit einer anderen (zweifelsfrei funktionierenden) Leitung in der Empfangseinrichtung. Wenn diese Verbindung hergestellt wird, lassen Sie das Telefon vom Fernsprecher überprüfen, ob die Telefonleitung zum Empfangsmodem geleitet wird.

     5. Wenn es sich um ein Ferngespräch handelt, lassen Sie die Anruferseite eine andere (zweifelsfrei funktionierende) Fernnetznummer ausprobieren. Wenn dies funktioniert, kann die Empfangsanlage oder -leitung nicht für Ferngespräche bereitgestellt werden. Wenn die ursprüngliche (BRI)-Leitung keine anderen Ferngesprächsnummern erreichen kann, ist die Fernverbindung möglicherweise nicht aktiviert. Testen Sie 1010-Codes für verschiedene Fernanbieter.

     6. Versuchen Sie abschließend eine andere (zweifelsfrei funktionierende) lokale Nummer von der BRI-Ausgangsleitung. Wenn die Verbindung immer noch fehlschlägt, lassen Sie den Telekommunikationsanbieter die BRI-Prüfung durchführen.

   • Möglichkeit 3: Die gewählte Nummer ist falsch. Überprüfen Sie die Nummer, indem Sie sie manuell wählen. Korrigieren Sie ggf. die Konfiguration.

   • Möglichkeit 4: Die Modemschulung dauert zu lange oder der TIMEOUT-Wert ist zu niedrig. Versuchen Sie, den TIMEOUT-Wert im Chat-Script-Befehl zu erhöhen. Wenn der TIMEOUT bereits 60 Sekunden oder länger ist, besteht möglicherweise ein Kabelproblem zwischen dem Modem und der DTE, an die es angeschlossen ist. Ausübungsfehler können auch auf ein Schaltungsproblem oder eine Modeminkompatibilität hinweisen.

     Um ein einzelnes Modemproblem zu beheben, gehen Sie zur AT-Eingabeaufforderung am ursprünglichen Modem mit Reverse Telnet. Verwenden Sie nach Möglichkeit das umgekehrte Telnet, um zur AT-Eingabeaufforderung des empfangenden Modems zu gelangen. Verwenden Sie ATM1, damit das Modem Töne an seinen Sprecher sendet, damit die Teilnehmer an jedem Ende hören können, was in der Leitung geschieht.

     Gibt es in der Musik ein Geräusch? Wenn ja, säubern Sie den Stromkreis. Wenn die Async-Modems nicht trainieren, rufen Sie die Nummer an, und achten Sie auf Statisch. Es können weitere Faktoren auftreten, die den Zugbetrieb beeinflussen. Umleiten von Telnet zum asynchronen Modem und Debuggen

5. Wenn alles gut funktioniert und Sie immer noch keine Verbindung mit Ihrem BRI-asynchronen Modem DDR herstellen können, versuchen Sie es mit PPP-Debugging. Wenn das Chat-Skript erfolgreich beendet wird und die PPP-Debugger einen Fehler anzeigen, lesen Sie den Abschnitt "Problembehandlung bei PPP" in Kapitel 17 des Internet-Leitfadens zur Fehlerbehebung.

BRI Async Modem DDR

Diese Funktion funktioniert nur auf der Cisco 3640-Plattform mit der Cisco IOS-Softwareversion 12.0(3)T oder höher. Hierfür ist eine spätere Hardware-Revision des BRI-Netzwerkmoduls erforderlich. Dies funktioniert nicht mit einer WAN-Schnittstellenkarte (WIC).

1. Stellen Sie sicher, dass die Ländervorwahl mit dem Befehl show modem korrekt ist. Verwenden Sie die folgenden Befehle, und versuchen Sie dann, einen Anruf zu tätigen:

   Warnung:  Wenn auf einem ausgelasteten System Debug ausgeführt wird, kann der Router abstürzen, indem die CPU überlastet oder der Konsolenpuffer überlastet wird!

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug bri
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. Bei Modemanrufen muss ein Chat-Skript ausgeführt werden, damit der Anruf fortgesetzt werden kann. Bei einem DDR, der auf einer Dialerzuordnung basiert, wird das Chat-Skript vom Modem-Script-Parameter in einem Dialer-Map-Befehl aufgerufen. Wenn der DDR auf einem Dialer-Profil basiert, wird dies über den in der TTY-Leitung konfigurierten Befehlsskripdialer erreicht. Beide Anwendungen basieren auf einem in der globalen Konfiguration des Routers vorhandenen Chat-Skript, z. B.:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   In beiden Fällen lautet der Befehl zum Anzeigen der Chat-Skriptaktivität Debug-Chat. Wenn der Wählzeichenfolge (Telefonnummer), der in der Wählerzuordnung oder dem Befehl Dialer-Zeichenfolge 551212 verwendet wird, würde die Debug-Ausgabe wie folgt aussehen:

   CHAT1: Attempting async line dialer script
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Stellen Sie sicher, dass das Chat-Skript den erwarteten Anruf (die richtige Nummer) basierend auf der "Sending String" versucht. Wenn das Chat-Skript nicht versucht, den erwarteten Anruf zu tätigen, überprüfen Sie die Konfiguration des Chat-Skripts. Verwenden Sie den Start-Chat-Befehl an der exec-Eingabeaufforderung, um das Chat-Skript manuell zu starten.

4. Anzeige von "Timeout Expecting: CONNECT" beschreibt mehrere Möglichkeiten:

   • Möglichkeit 1: Das lokale Modem führt den Anruf nicht aus. Stellen Sie sicher, dass das Modem einen Anruf tätigen kann, indem es ein umgekehrtes Telnet zum Modem durchführt und manuell eine Rufnummer initiiert. Wenn das Remote-Ende anscheinend nicht antwortet, stellen Sie sicher, dass der Anruf vom Modem getätigt wird, indem Sie eine lokale Nummer manuell mit dem Befehl ATDT<number> anrufen und auf den Klingelton hören. Wenn kein Anruf beendet wird, aktivieren Sie ISDN-Debug. Überprüfen Sie bei dem ersten Verdacht auf einen ISDN-Ausfall auf einem BRI immer den Ausgang vom show isdn status. Zu beachten ist vor allem, dass Layer 1 aktiv sein sollte und Layer 2 sich im Zustand MULTIPLE_FRAME_ESTABLISHED befinden sollte. Weitere Informationen zum Lesen dieser Ausgabe und zu den entsprechenden Korrekturmaßnahmen finden Sie im Internet-Fehlerbehebungshandbuch Kapitel 16 "Interpreting Show ISDN Status" (Interpreting des ISDN-Status).

     Für ausgehende ISDN-Anrufe sind debug isdn q931 und debug isdn event die besten Tools. Glücklicherweise ähnelt das Debuggen ausgehender Anrufe dem Debuggen eingehender Anrufe. Ein normaler erfolgreicher Anruf könnte wie folgt aussehen:

     *Mar 20 21:07:45.025: ISDN BR0: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
     

     Beachten Sie, dass die CONNECT-Nachricht der Schlüsselindikator für den Erfolg ist. Wenn keine CONNECT-Nachricht empfangen wird, wird möglicherweise eine DISCONNECT- oder eine RELEASE_COMP-Nachricht (Release Complete) angezeigt, gefolgt von einem Ursachencode:

     *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
     callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     Der Ursachenwert weist auf zwei Dinge hin.

     • Das zweite Byte des 4- oder 6-Byte-Werts gibt den Punkt im End-to-End-Anrufpfad an, von dem der DISCONNECT oder RELEASE_COMP empfangen wurde. Dies kann Ihnen helfen, das Problem zu lokalisieren.

     • Das dritte und vierte Byte geben den tatsächlichen Grund für den Ausfall an. Die Bedeutung der verschiedenen Werte finden Sie in Tabelle 9.

   • Möglichkeit 2: Das Remote-Modem antwortet nicht. Testen Sie dies, indem Sie das Remote-Modem mit einem normalen Telefon wählen. Versuchen Sie es:

     1. Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen.

     2. Stellen Sie sicher, dass ein manueller Anruf das beantwortende async-Modem erreichen kann. Wenn ein manueller Anruf das beantwortende async-Modem erreichen kann, wird die BRI-Leitung möglicherweise nicht für ausgehende Sprachanrufe bereitgestellt.

     3. Wenn ein manueller Anruf das beantwortende asynchrone Modem nicht erreichen kann, wechseln Sie die Telefonkabel des Empfangsmodems, und versuchen Sie, ein normales Telefon an der Leitung des empfangenden Modems zu verwenden. Wenn der Anruf vom regulären Telefon empfangen werden kann, besteht wahrscheinlich ein Problem mit dem empfangenden Modem.

     4. Wenn der manuelle Anruf auf der betreffenden Leitung immer noch nicht am regulären Telefon ankommt, versuchen Sie es mit einer anderen (zweifelsfrei funktionierenden) Leitung in der Empfangseinrichtung. Wenn diese Verbindung hergestellt wird, lassen Sie das Telefon vom Fernsprecher überprüfen, ob die Telefonleitung zum Empfangsmodem geleitet wird.

     5. Wenn es sich um ein Ferngespräch handelt, lassen Sie die Anruferseite eine andere (zweifelsfrei funktionierende) Fernnetznummer ausprobieren. Wenn dies funktioniert, kann die Empfangsanlage oder -leitung nicht für Ferngespräche bereitgestellt werden. Wenn die ursprüngliche (BRI)-Leitung keine anderen Ferngesprächsnummern erreichen kann, ist die Fernverbindung möglicherweise nicht aktiviert. Testen Sie 10-10 Codes für verschiedene Fernanbieter.

     6. Versuchen Sie abschließend eine andere (zweifelsfrei funktionierende) lokale Nummer von der BRI-Ausgangsleitung. Wenn die Verbindung immer noch fehlschlägt, lassen Sie den Telekommunikationsanbieter die BRI-Prüfung durchführen.

   • Möglichkeit 3: Die gewählte Nummer ist falsch. Überprüfen Sie die Nummer, indem Sie sie manuell wählen. Korrigieren Sie ggf. die Konfiguration.

   • Möglichkeit 4: Die Modemschulung dauert zu lange, oder der TIMEOUT-Wert ist zu niedrig. Versuchen Sie, den TIMEOUT-Wert im Chat-Script-Befehl zu erhöhen. Wenn der TIMEOUT bereits 60 Sekunden oder länger ist, besteht möglicherweise ein Kabelproblem zwischen dem Modem und der DTE, an die es angeschlossen ist. Ausübungsfehler können auch auf ein Schaltungsproblem oder eine Modeminkompatibilität hinweisen.

     Um ein einzelnes Modemproblem zu beheben, gehen Sie zur AT-Eingabeaufforderung am ursprünglichen Modem mit Reverse Telnet. Verwenden Sie nach Möglichkeit das umgekehrte Telnet, um zur AT-Eingabeaufforderung des empfangenden Modems zu gelangen. Verwenden Sie ATM1, damit das Modem Töne an seinen Sprecher sendet, damit die Teilnehmer an jedem Ende hören können, was in der Leitung geschieht.

     Gibt es in der Musik ein Geräusch? Wenn ja, säubern Sie den Stromkreis. Wenn die Async-Modems nicht trainieren, rufen Sie die Nummer an, und achten Sie auf Statisch. Es können weitere Faktoren auftreten, die den Zugbetrieb beeinflussen. Umleiten von Telnet zum asynchronen Modem und Debuggen

5. Wenn alles gut funktioniert und Sie immer noch keine Verbindung mit Ihrem BRI-asynchronen Modem DDR herstellen können, versuchen Sie es mit PPP-Debugging. Wenn das Chat-Skript erfolgreich beendet wird und die PPP-Debugger einen Fehler anzeigen, lesen Sie den Abschnitt "Problembehandlung bei PPP" in Kapitel 17 des Internet-Leitfadens zur Fehlerbehebung.

PRI ISDN DDR

1. Überprüfen Sie bei dem ersten Verdacht auf einen ISDN-Ausfall auf einem PRI immer den Ausgabe-Status "show isdn". Zu beachten ist vor allem, dass Layer 1 aktiv sein sollte und Layer 2 MULTIPLE_FRAME_ESTABLISHED sein sollte. Weitere Informationen zum Lesen dieser Ausgabe und zu den entsprechenden Korrekturmaßnahmen finden Sie im Internet-Fehlerbehebungshandbuch Kapitel 16 "Interpreting Show ISDN Status" (Interpreting des ISDN-Status).

   Für ausgehende ISDN-Anrufe sind debug isdn q931 und debug isdn event die besten Tools. Glücklicherweise ähnelt das Debuggen ausgehender Anrufe dem Debuggen eingehender Anrufe. Ein normaler erfolgreicher Anruf könnte wie folgt aussehen:

   *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
   Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
   callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
   

   Beachten Sie, dass die CONNECT-Nachricht der Schlüsselindikator für den Erfolg ist. Wenn keine CONNECT-Nachricht empfangen wird, wird möglicherweise eine DISCONNECT- oder eine RELEASE_COMP-Nachricht (Release Complete) angezeigt, gefolgt von einem Ursachencode:

   *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   Der Ursachenwert weist auf zwei Dinge hin.

   • Das zweite Byte des 4- oder 6-Byte-Werts gibt den Punkt im End-to-End-Anrufpfad an, von dem der DISCONNECT oder RELEASE_COMP empfangen wurde. Dies kann Ihnen helfen, das Problem zu lokalisieren.

   • Das dritte und vierte Byte geben den tatsächlichen Grund für den Ausfall an. Die Bedeutung der verschiedenen Werte finden Sie in Tabelle 9.

   Hinweis: Der folgende Ausdruck weist auf einen Fehler des höheren Protokolls hin:

   Cause i = 0x8090 - Normal call clearing

   Der Ausfall der PPP-Authentifizierung ist ein typischer Grund. Aktivieren Sie Debug-PPP-Aushandlung und Debug-PPP-Authentifizierung, bevor Sie davon ausgehen, dass der Verbindungsausfall zwangsläufig ein ISDN-Problem ist.

2. Wenn die Meldung ISDN CONNECT (ISDN-VERBINDUNG) angezeigt wird und die PPP-Debugger einen Fehler anzeigen, lesen Sie den Abschnitt "Problembehandlung bei PPP" in Kapitel 17 des Leitfadens zur Internetwork-Fehlerbehebung.

BRI ISDN DDR

1. Überprüfen Sie bei dem ersten Verdacht auf einen ISDN-Ausfall auf einem BRI immer den Ausgabe-Status von show isdn. Zu beachten ist vor allem, dass Layer 1 aktiv sein muss und Layer 2 MULTIPLE_FRAME_ESTABLISHED aufweisen muss. Informationen zum Lesen dieser Ausgabe und Korrekturmaßnahmen finden Sie im Internet-Fehlerbehebungsleitfaden Kapitel 16, "Interpreting Show ISDN Status" (ISDN-Status anzeigen).

   Für ausgehende ISDN-Anrufe sind debug isdn q931 und debug isdn event die besten Tools. Glücklicherweise ähnelt das Debuggen ausgehender Anrufe dem Debuggen eingehender Anrufe. Ein normaler erfolgreicher Anruf könnte wie folgt aussehen:

   *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
   *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
   

   Beachten Sie, dass die CONNECT-Nachricht der Schlüsselindikator für den Erfolg ist. Wenn keine CONNECT-Nachricht empfangen wird, wird möglicherweise eine DISCONNECT- oder eine RELEASE_COMP-Nachricht (Release Complete) angezeigt, gefolgt von einem Ursachencode:

   *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   Der Ursachenwert weist auf zwei Dinge hin.

   • Das zweite Byte des 4- oder 6-Byte-Werts gibt den Punkt im End-to-End-Anrufpfad an, von dem der DISCONNECT oder RELEASE_COMP empfangen wurde. Dies kann Ihnen helfen, das Problem zu lokalisieren.

   • Das dritte und vierte Byte geben den tatsächlichen Grund für den Ausfall an. Die Bedeutung der verschiedenen Werte finden Sie in Tabelle 9.

     Hinweis: Der folgende Ausdruck weist auf einen Fehler des höheren Protokolls hin:

     Cause i = 0x8090 - Normal call clearing

     Der Ausfall der PPP-Authentifizierung ist ein typischer Grund. Aktivieren Sie Debug-PPP-Aushandlung und Debug-PPP-Authentifizierung, bevor Sie davon ausgehen, dass der Verbindungsausfall zwangsläufig ein ISDN-Problem ist.

2. Wenn die Meldung ISDN CONNECT (ISDN-VERBINDUNG) angezeigt wird und die PPP-Debugger einen Fehler anzeigen, lesen Sie den Abschnitt "Problembehandlung bei PPP" in Kapitel 17 des Leitfadens zur Internetwork-Fehlerbehebung.

Zugehörige Informationen

• Cisco IOS-Schnellkonfigurationsanleitung für Dial-Services
• Konfigurationsleitfaden für Cisco IOS-Wähldienste: Netzwerkservices
• Konfigurationsleitfaden für Cisco IOS-Wähldienste: Terminaldienste
• Befehlsreferenz für Cisco IOS-Wähldienste
• Dial-Fallstudie - Übersicht
• Technologieseiten aufrufen
• Technischer Support und Dokumentation - Cisco Systems