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.
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:
Cisco IOS-DDR (Dial-on-Demand Routing)
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.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
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:
Lässt sich ein Anruf über das DFÜ-Routing (Dial on Demand Routing, DDR) initiieren? (Eine Ja-Antwort bringt uns zur nächsten Frage.)
Wenn es sich um ein asynchrones Modem handelt, stellen die Chat-Skripte die erwarteten Befehle aus?
Macht der Anruf es zum PSTN?
Wird der Anruf vom Remote-Ende angenommen?
Wird der Anruf beendet?
Werden Daten über den Link übertragen?
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).
Tabelle 1: Der Datenverkehr initiiert keinen Wählversuch.Mögliche Ursachen | Empfohlene Aktionen |
---|---|
Fehlende oder falsche Definitionen für "interessanten Datenverkehr" |
|
Schnittstellenstatus | Verwenden Sie den Befehl show interfaces <interface name>, um sicherzustellen, dass sich die Schnittstelle im Zustand "up/up (spoofing)" befindet. |
|
Eine andere (primäre) Schnittstelle am Router wurde so konfiguriert, dass sie die Dialer-Schnittstelle als Backup-Schnittstelle verwendet. Darüber hinaus befindet sich die primäre Schnittstelle nicht im Zustand "Down/down" (Herunterfahren/Herunterfahren), was erforderlich ist, um die Dialer-Schnittstelle aus dem Standby-Modus zu holen. Darüber hinaus muss eine Sicherungsverzögerung auf der primären Schnittstelle konfiguriert werden, oder der Befehl für die Sicherungsschnittstelle wird niemals erzwungen. Um sicherzustellen, dass die Dialer-Schnittstelle von "Standby" zu "Up/Up (Spoofing)" wechselt, muss das Kabel in der Regel von der primären Schnittstelle abgezogen werden. Wenn Sie die primäre Schnittstelle einfach mithilfe des Konfigurationsbefehls herunterfahren, wird die primäre Schnittstelle nicht in "down/down" gesetzt, sondern in "administrativ heruntergefahren" ? nicht dasselbe. Wenn die primäre Verbindung über Frame Relay erfolgt, muss die Frame-Relay-Konfiguration auf einer Point-to-Point Serial Subschnittstelle erfolgen, und die Telefongesellschaft muss das "aktive" Bit übergeben. Diese Vorgehensweise wird auch als "End-to-End Local Management Interface (LMI)" bezeichnet. |
|
Die Dialer-Schnittstelle wurde mit dem Befehl shutdown konfiguriert. Dies ist auch der Standardstatus einer beliebigen Schnittstelle, wenn ein Cisco Router zum ersten Mal gestartet wird. Verwenden Sie den Befehl interface configuration no shutdown, um dieses Hindernis zu entfernen. |
Falsches Routing | Geben Sie den Befehl exec show ip route [a.b.c.d] ein, wobei a.b.c.d die Adresse der Dialer-Schnittstelle des Remote-Routers ist. Wenn ip unnumbered (nicht nummerierte IP) auf dem Remote-Router verwendet wird, verwenden Sie die Adresse der Schnittstelle, die im Befehl ip unnumbered (nicht nummerierte IP) aufgeführt ist. Die Ausgabe sollte eine Route zur Remote-Adresse über die Dialer-Schnittstelle anzeigen. Wenn keine Route vorhanden ist, stellen Sie sicher, dass statische oder Floating-statische Routen konfiguriert wurden, indem Sie die Ausgabe von show running-config prüfen. Wenn eine Route über eine andere Schnittstelle als die Dialer-Schnittstelle existiert, impliziert dies, dass DDR als Backup verwendet wird. Überprüfen Sie die Router-Konfiguration, um sicherzustellen, dass statische oder Floating-statische Routen konfiguriert wurden. Der sicherste Weg, das Routing zu testen, besteht in diesem Fall darin, die primäre Verbindung zu deaktivieren und den Befehl show ip route [a.b.c.d] auszuführen, um zu überprüfen, ob die richtige Route in der Routing-Tabelle installiert wurde. Hinweis: Wenn Sie dies während des Live-Netzwerkbetriebs versuchen, kann ein Wählereignis ausgelöst werden. Diese Art von Tests lässt sich am besten in planmäßigen Wartungszyklen durchführen. |
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.
Tabelle 2: Anruf nicht getätigtMögliches Problem | Empfohlene Maßnahmen |
---|---|
Falsch konfigurierte Wählzuordnung | Verwenden Sie den Befehl show running-config, um sicherzustellen, dass die Wählschnittstelle mit mindestens einer Wählzuordnungsanweisung konfiguriert ist, die auf die Protokolladresse und die angerufene Nummer der Remotesite zeigt. |
Falsch konfiguriertes Wählprofil | Verwenden Sie den Befehl show running-config, um sicherzustellen, dass die Dialer-Schnittstelle mit dem Befehl Dialer pool X konfiguriert ist und dass eine Dialer-Schnittstelle auf dem Router mit einem übereinstimmenden Dialer-Pool-Mitglied-X konfiguriert ist. Wenn Wählprofile nicht ordnungsgemäß konfiguriert sind, wird möglicherweise folgende Fehlerbehebungsmeldung angezeigt: Dialer1: Can't place call, no dialer pool setStellen Sie sicher, dass eine Wählzeichenfolge konfiguriert ist. |
Identifizieren Sie anschließend den verwendeten Medientyp:
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
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
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.
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:
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.
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.
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.
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.
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
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.
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.)
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
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.
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:
Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen.
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.
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.
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.
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.
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
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.
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
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
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.
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:
Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen.
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.
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.
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.
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.
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
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.
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).
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
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
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.
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:
Stellen Sie sicher, dass die angerufene Telefonnummer korrekt ist. Verwenden Sie einen Hörer, um die Empfangsnummer anzurufen.
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.
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.
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.
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.
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
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.
Ü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.
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.
Ü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.
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.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
09-Jul-2007 |
Erstveröffentlichung |