Flussdiagramm zur ISDN BRI-Fehlerbehebung
Inhalt
Einführung
Dieses Dokument unterstützt Sie bei der Fehlerbehebung beim Einwahlzugriff über die ISDN-Basisanschluss (Basic Rate Interface, BRI). Im Flussdiagramm und der unten gezeigten Beispielausgabe haben wir mithilfe von Dialer-Profilen eine ISDN-BRI-Verbindung zu einem anderen System eingerichtet. Die gleichen Fehlerbehebungsschritte gelten jedoch für Verbindungen mit anderen Routern (z. B. Zweigstellen) und bei der Verwendung von Legacy Dial-on-Demand Routing (DDR).
Hinweis: Sie können auch die Cisco Support Community verwenden, um Ihnen bei der Lösung Ihres ISDN-Problems zu helfen.
Einführende Informationen zu ISDN und DDR finden Sie in der Audioschulung in der Cisco Learning Connection.
Flussdiagramm
Klicken Sie auf einen Link unten, um weitere Informationen zu dem Artikel zu erhalten. Kehren Sie mit der Schaltfläche Zurück Ihres Browsers zu diesem Flussdiagramm zurück.
Fehlerbehebung: Anmelden und Erfassen dieser Debugger
Sie können eine Verbindung zum Router entweder über das Konsolenkabel herstellen, das an den seriellen Port Ihres PCs angeschlossen ist, oder über Telnet.
Wenn Sie über die Konsole eine Verbindung zum Router herstellen müssen, lesen Sie die Informationen zum Anwenden der richtigen Terminal-Emulatoreinstellungen für Konsolenverbindungen. Wenn Ihr Router bereits für die Verbindung mit dem Ethernet eingerichtet ist und Sie eine Telnet-Verbindung mit Ihrem Router herstellen möchten, verwenden Sie einfach einen Telnet-Client, um eine Verbindung mit der Ethernet-IP-Adresse des Routers herzustellen.
In jedem Fall (Konsole oder Telnet) ist es besser, einen Client zu verwenden, der es Ihnen ermöglicht, eine Verlaufsübersicht über die während der Sitzung empfangenen Ausgaben zu speichern, da Sie möglicherweise in der Debugausgabe einen Bildlauf nach bestimmten Meldungen durchführen müssen.
Aktivieren Sie Millisekunden für die Debug-Ausgabe und die Protokollmeldungen. Geben Sie bei Aufforderung das auf Ihrem Router konfigurierte Kennwort ein, und wechseln Sie in den Aktivierungsmodus:
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Wenn Sie mit telnet verbunden sind, geben Sie terminal monitor wie folgt ein:
router#terminal monitor router#
Geben Sie anschließend die folgenden Debugbefehle ein:
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
Initiieren Sie anschließend den Ping-Befehl am anrufenden Router. Im Folgenden finden Sie ein Beispiel für die Debugausgabe eines erfolgreichen Aufrufs. Die verschiedenen Phasen, die im Flussdiagramm angegeben sind, werden hervorgehoben.
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
Zurück zum Fehlerbehebungs-Flussdiagramm
Fehlerbehebung: Versucht der Router zu wählen?
Um herauszufinden, ob der Router versucht, einen Anruf zu tätigen, überprüfen Sie, ob die folgenden Zeilen in der Debug-Ausgabe des anrufenden Routers enthalten sind:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
In der Debug-Ausgabe ist 8134 die ISDN-Verzeichnisnummer, die der Router zu wählen versucht. Diese Nummer wurde mit dem Befehl dialer string oder dialer map angegeben.
Zurück zum Fehlerbehebungs-Flussdiagramm
Symptom: Der Router versucht nicht zu wählen.
Wenn Ihr Router nicht anwählt, gibt es mehrere Möglichkeiten:
Keine Debug-Ausgabe
Wenn es überhaupt keine Debug-Ausgabe gibt, ist dies höchstwahrscheinlich, weil das IP-Paket, das Sie senden, nicht einmal an die Dialer-Schnittstelle weitergeleitet wird. Die häufigsten Ursachen hierfür sind:
- Überprüfen Sie, ob die IP-Adresse auf der Dialer-Schnittstelle konfiguriert ist. Sie sollten entweder über eine IP-Adresse auf der Dialer-Schnittstelle oder über eine nicht nummerierte IP-Schnittstelle verfügen (wobei die Schnittstelle eine up/up-Schnittstelle ist, wie Ethernet x, Loopback x usw.) oder über eine IP-Adresse verfügen, die ausgehandelt wird (wenn der Client eine IP-Adresse vom NAS erhält). Wenn Sie Legacy-DDR verwenden, sollte die IP-Adresse auf der physischen Schnittstelle konfiguriert werden (z. B. Schnittstelle BRI 0).
- Überprüfen Sie, ob der Befehl ip routing konfiguriert ist. Wenn Sie Ihre Konfiguration mit dem Befehl show running-config betrachten, sollten Sie nicht den Befehl no ip routing sehen.
- Überprüfen Sie, ob eine statische Route auf die Dialer-Schnittstelle oder den nächsten Hop zeigt (wenn Sie Dialer-Karten verwenden).
Das folgende Beispiel (für das Wählerprofil) ist eine statische Route für 172.22.53.0/24 mit dem nächsten Hop-Dialer 1:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
Das folgende Beispiel (für Legacy-DDR) ist eine statische Route für 172.22.53.0/24 mit dem nächsten Hop 172.16.1.1. Die nächste Hop-Adresse muss mit der IP-Adresse in der Wählplananweisung übereinstimmen, die für die Wählscheibe verwendet wird:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- Stellen Sie sicher, dass der Dialer oder die physische Schnittstelle nicht administrativ ausgefallen oder im Standby-Modus ist. Mit dem Befehl show interface dialer X oder show interface bri X können Sie sicherstellen, dass sich die Schnittstelle im Status up/up (Spoofing) befindet.
Wenn die Schnittstelle vom Administrator deaktiviert wurde, verwenden Sie den Befehl no shutdown im Schnittstellenkonfigurationsmodus.
Wenn sich die Schnittstelle im Standby-Modus befindet, dient die Dialer- oder BRI-Schnittstelle als Backup für eine eingeschaltete Verbindung. Sie können den Befehl Backup Interface (Backup-Schnittstelle) unter der primären Schnittstelle entfernen oder das Kabel von der primären Schnittstelle abziehen.
Es ist eine Debug-Ausgabe vorhanden, aber keine Nachricht "Versuch, zu wählen".
In diesem Fall wird wahrscheinlich ein IP-Paket an die Schnittstelle weitergeleitet, der Router verwirft es jedoch und initiiert den Anruf aus irgendeinem Grund nicht. Sehen Sie sich die Debug-Ausgabe an, um herauszufinden, warum der Anrufversuch nicht durchgeführt wurde. Im Folgenden finden Sie einige Beispiele für Debug-Ausgaben und deren mögliche Gründe:
Beispiel 1
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
Der generierte Datenverkehr stimmt nicht mit der interessanten Verkehrsdefinition überein. Ändern Sie in diesem Beispiel die Zugriffsliste 101.
Eine einfache, interessante Verkehrsdefinition wäre, den gesamten IP-Datenverkehr wie folgt zu erlauben:
maui-soho-01(config)#dialer-list 1 protocol ip permit
Warnung: Wenn der gesamte IP-Datenverkehr als interessant markiert wird, kann die ISDN-Verbindung unbegrenzt verfügbar bleiben, insbesondere wenn Sie über ein Routing-Protokoll oder einen anderen regelmäßigen Datenverkehr verfügen. Passen Sie die interessante Verkehrsdefinition an Ihre Anforderungen an.
Weitere Informationen zu interessantem Datenverkehr finden Sie im Dokument Dialup Technology: Übersichten und Erklärungen.
Beispiel 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (no dialer-group defined).
Auf der Dialer-Schnittstelle ist keine Dialer-Gruppe konfiguriert. Fügen Sie eine Dialer-Gruppe hinzu, wie im folgenden Beispiel gezeigt:
interface Dialer1 dialer-group X
Hinweis: Der Wert für X muss mit dem Befehl dialer-list identisch sein.
Beispiel 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (dialer-list 1 not defined).
Es gibt eine Dialer-Gruppe-Anweisung auf der Dialer-Schnittstelle, aber die genannte Dialer-Liste existiert nicht. Konfigurieren Sie die Dialer-Liste wie im folgenden Beispiel:
dialer-list X protocol ip permit
Hinweis: Der Wert für X muss mit dem Befehl dialer-group unter der Dialer-Schnittstelle identisch sein.
Beispiel 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.
In diesem Fall ist das ausgehende Paket als interessant genug anzusehen, um die Verbindung aufzurufen. Es steht jedoch keine physische Schnittstelle zum Tätigen des Anrufs zur Verfügung. Stellen Sie sicher, dass das Dialer-Pool-Mitglied X in der physischen Schnittstelle konfiguriert ist und der Dialer-Pool X in der Dialer-Schnittstelle konfiguriert ist. Beispiel:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
Stellen Sie außerdem sicher, dass die BRI-Schnittstelle nicht heruntergefahren ist.
Beispiel 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.
In diesem Fall ist auf der Dialer-Schnittstelle keine Dialer-Zeichenfolge konfiguriert. Der Router möchte einen Anruf tätigen, kennt jedoch die ISDN-Verzeichnisnummer für den Anruf nicht. Definieren einer Dialer-Zeichenfolge:
interface Dialer1 dialer string 8134
Weitere Informationen zur Fehlerbehebung finden Sie im Abschnitt "Der anrufende Router sendet keine SETUP-Nachricht" im Dokument Fehlerbehebung für ISDN BRI Layer 3 mit dem Befehl debug isdn q931.
Zurück zum Fehlerbehebungs-Flussdiagramm
Fehlerbehebung: Ist die ISDN Call Connect erfolgreich?
Um festzustellen, ob der ISDN-Anruf eine Verbindung herstellt, suchen Sie im Debugger nach einer CONNECT_ACK- und %LINK-3-UPDOWN-Nachricht:
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
Wenn Sie diese Meldung sehen, wird Ihr ISDN-Anruf erfolgreich verbunden, und Sie können mit dem nächsten Schritt fortfahren. Wenn Sie keine Meldung wie diese sehen, lesen Sie unten für mögliche Ursachen.
Zurück zum Fehlerbehebungs-Flussdiagramm
Symptom: Der ISDN-Anruf stellt keine Verbindung her.
- Wenn die Ausgabe ähnlich der folgenden aussieht, stellen Sie sicher, dass das ISDN-Kabel sowohl an den Router als auch an die Telco-Buchse angeschlossen ist.
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- Überprüfen Sie, ob der ISDN-Schaltkreis ordnungsgemäß funktioniert. Mit dem Befehl show isdn status können Sie überprüfen, ob Layer 1 AKTIV ist, Layer 2 MULTIPLE_FRAME_ESTABLISHED ist und die SPIDs (falls erforderlich) gültig sind. Weitere Informationen finden Sie im Dokument Verwenden des Befehls show isdn status für die BRI-Fehlerbehebung.
Wenn der Befehl show isdn status von Ihrem Cisco Gerät ausgegeben wird, können Sie Cisco CLI Analyzer zur Anzeige potenzieller Probleme und Fixes verwenden. Um den Cisco CLI Analyzer verwenden zu können, müssen Sie ein registrierter Benutzer sein, angemeldet sein und JavaScript aktivieren. - Überprüfen Sie, ob die konfigurierte ISDN-Wählzeichenfolge korrekt ist. Beachten Sie, dass Sie möglicherweise eine führende Null, neun oder andere Ziffern hinzufügen müssen, um eine externe Leitung zu erhalten, wenn Sie über ein PBX-System verbunden sind.
- Wenn für die Verbindung ein Fernsprecher verwendet wird, wenden Sie sich an Ihren lokalen Fernsprechanbieter und Fernsprechanbieter, um zu überprüfen, ob der Dienst aktiviert ist. Häufig ist die ISDN-Leitung beim lokalen Telco falsch konfiguriert, sodass ausgehende ISDN-Ferngespräche nicht an das entsprechende Ferngesprächnetz weitergeleitet werden. Sie sollten auch überprüfen, ob das Netzwerk der Fernanbieter funktioniert.
In den USA und in Situationen, in denen der Telekommunikationsanbieter oder der Anbieter von Ferngesprächen das Problem nicht beheben kann, können Sie einen vorab abonnierten Interexchange Carrier (PIC) verwenden. PIC-Codes sind siebenstellige Präfixe, die US-Fernnetzbetreiber mit lokalen Wechselstuben (LEC) identifizieren. So können Kunden für individuelle Anrufe verschiedene Ferngespräche nutzen. Der PIC-Code wird als Präfix für die gewählte Nummer konfiguriert. Die meisten PICs haben das Format 1010xxx.
Verwenden Sie keine Wählzeichenfolge xxxxx oder keine Wählzuordnung, um die vorhandene Nummer zu entfernen, und konfigurieren Sie dann die neue Nummer.
Zum Beispiel Dialer-Zeichenfolge 10103215125551111.
- Suchen Sie nach einer ISDN-Trennungsmeldung.
Die Cisco IOS®-Software decodiert den Ursachencode in dieser Trennungsmeldung und gibt Ihnen eine klare Textnachricht, die häufig nützliche Informationen enthält, die zur Ursache des Problems führen. Hier finden Sie möglicherweise folgende Zeichenfolgen:
- Nicht zugewiesene oder nicht zugewiesene Nummer
- Inkompatibles Ziel (beide weisen darauf hin, dass die gewählte Nummer falsch ist)
- Nummer belegt (d. h. die angerufene Seite ist besetzt)
- Vorübergehender Ausfall (ein Hinweis auf einen vorübergehenden Ausfall des Telco-Netzwerks)
Um den möglichen Grund für eine bestimmte Trennungsursache zu finden, lesen Sie Verständnis von debug isdn q931 Disconnect Cause Codes.
Beispielsweise kann eine Verbindungsunterbrechung aufgrund einer falschen ISDN-Nummer angezeigt werden mit:
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
Unter Bezugnahme auf das zuvor erwähnte Disconnect Cause Codes können feststellen, dass der Trenncode durch den Versuch verursacht wurde, eine Verbindung zu einem Nicht-ISDN-Gerät (z. B. einer analogen Leitung) herzustellen.
Eine Trennung aufgrund einer falsch formatierten Zahl kann angezeigt werden mit:
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)Unter Bezugnahme auf das Dokument Understanding isdn q931 Disconnect Cause Codes können wir feststellen, dass der Trennungscode durch ein ungültiges Format für die Remote-ISDN-Nummer verursacht wurde. Die Verbindung schlägt fehl, weil die Zieladresse (an den Switch) in einem nicht erkennbaren Format angezeigt wird oder die Zieladresse unvollständig ist.
Das folgende Beispiel zeigt einen abgelehnten Anruf aufgrund einer falschen ISDN-Nummer:
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- Wenn Ihnen Ihr Telco Serviceprofil-IDs (SPIDs) zur Verfügung gestellt hat, stellen Sie sicher, dass diese SPIDs auf der BRI-Schnittstelle konfiguriert sind. SPIDs werden in der Regel nur in den USA und bei NI- und DMS-Switchtypen verwendet (5-lose Switchypes benötigen keine SPIDs).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
Mit dem Befehl show isdn status können Sie überprüfen, ob die SPIDs korrekt sind.
Weitere Informationen finden Sie im Dokument Troubleshooting ISDN BRI SPIDs.
Wenn der Befehl show isdn status von Ihrem Cisco Gerät ausgegeben wird, können Sie Cisco CLI Analyzer zur Anzeige potenzieller Probleme und Fixes verwenden. Um den Cisco CLI Analyzer verwenden zu können, müssen Sie ein registrierter Benutzer sein, angemeldet sein und JavaScript aktivieren. - Wenn das Problem mit dem oben beschriebenen Verfahren nicht behoben wurde, verwenden Sie das Dokument Troubleshooting ISDN BRI Layer 3 unter Verwendung des Befehls debug isdn q931 für die weitere Fehlerbehebung.
Zurück zum Fehlerbehebungs-Flussdiagramm
Fehlerbehebung: Ist die PPP-LCP-Phase erfolgreich?
In der Debugausgabe sollte eine Meldungszeile zu folgendem angezeigt werden:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
Wenn Sie diese Zeile sehen, bedeutet dies, dass das Link Control Protocol (LCP) erfolgreich ausgehandelt wurde. Ein anderer Status als "offen" weist darauf hin, dass LCP fehlerhaft ist.
Zurück zum Fehlerbehebungs-Flussdiagramm
Symptom: PPP-LCP-Phase ist nicht erfolgreich
Mögliche Ursache: PPP ist nicht konfiguriert.
Wenn die Debug-Ausgabe ähnlich den folgenden Zeilen ist, zeigt dies an, dass PPP nicht gestartet wurde.
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
Beachten Sie aus der Debug-Ausgabe, dass der Router keine PPP CONFREQ-Nachrichten sendet. Dies liegt vermutlich daran, dass die Schnittstelle nicht für die PPP-Kapselung konfiguriert wurde.
Überprüfen Sie in diesem Fall, ob Sie den Befehl encapsulation ppp unter der Dialer-Schnittstelle und der physischen Schnittstelle konfiguriert haben. Beispiele:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
Mögliche Ursache: Nichtübereinstimmung der ISDN-Geschwindigkeit
Manchmal sehen Sie nur ausgehende LCP CONFREQ-Nachrichten, aber keine eingehenden LCP-Nachrichten. Nachstehend ein Beispiel:
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
Dieses Problem kann durch folgende Faktoren verursacht werden:
- Das Remote-Ende wird nicht für PPP konfiguriert. Konfigurieren Sie den Befehl encapsulation ppp am Remote-Ende.
- Pakete, die nicht über das Übertragungsmedium gelangen. Die häufigste Ursache dafür ist eine Nichtübereinstimmung der ISDN-Geschwindigkeit.
Aus ISDN-Perspektive betrachtet besteht das Problem darin, dass die eine Seite wahrscheinlich eine Verbindung mit 56.000 herstellt, während die andere Seite eine Verbindung mit 64.000 herstellt. Es ist möglich, dass die lokale oder Remote-Leitung die Standard-64K-Verbindungen nicht unterstützt. Versuchen Sie, beide Enden zu konfigurieren, um mit 56k zu arbeiten.
Für Dialer-Profile:
maui-soho-01(config)#interface Dialer1 maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
Für Legacy-DDR (Dialer-Karten):
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
Mögliche Ursache: Die beiden Router sind nicht einverstanden mit einem zu verwendenden Authentifizierungsprotokoll (CHAP oder PAP)
Wenn die Debug-Ausgabe ähnlich den folgenden Zeilen ist, weist dies darauf hin, dass der Router und die Remote-Seite sich nicht auf ein zu verwendendes Authentifizierungsprotokoll geeinigt haben:
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
Überprüfen Sie in diesem Fall, ob Sie Folgendes konfiguriert haben:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
Weitere Informationen zu Challenge Handshake Authentication Protocol (CHAP) oder Password Authentication Protocol (PAP) finden Sie in den folgenden Dokumenten:
- PPP CHAP-Authentifizierung verstehen und konfigurieren
- PPP-Authentifizierung mithilfe der Befehle ppp chap hostname und ppp authentication chap callin
- Konfiguration und Fehlerbehebung für PPP Password Authentication Protocol (PAP)
Sie können die Cisco Support Community auch zur weiteren PPP-Fehlerbehebung verwenden.
Zurück zum Fehlerbehebungs-Flussdiagramm
Fehlerbehebung: Wurde die PPP-Authentifizierung erfolgreich durchgeführt?
Überprüfen Sie die Debug-Ausgabe für eine Zeile, die dieser ähnelt:
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
Zurück zum Fehlerbehebungs-Flussdiagramm
Symptom: PPP-Authentifizierung ist nicht erfolgreich
Stellen Sie sicher, dass Sie die folgenden Posten konfiguriert haben:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
Im Beispiel ist XXXXX Ihr Benutzername und YYYY Ihr Kennwort.
Hinweis: Konfigurieren Sie nur den Benutzernamen und das Kennwort für die Authentifizierungsmethode, die Sie und Ihr Peer verwenden. Wenn Sie z. B. beide PAP nicht verwenden, benötigen Sie den Befehl "ppp pap sent-username" nicht. Wenn Sie jedoch nicht sicher sind, ob der Peer PAP oder CHAP unterstützt, konfigurieren Sie beide.
Je nach Version und Konfiguration der Cisco IOS-Software wird das Kennwort möglicherweise verschlüsselt in Ihrer Konfiguration angezeigt. Wenn dies der Fall ist, sehen Sie beim Ausführen eines Befehls show running-configuration das Wort "password" gefolgt von der Ziffer 7 und dann eine Zahlenfolge, wie im folgenden Beispiel:
interface Dialer1 ppp chap password 7 140005
In diesem Fall können Sie nicht überprüfen, ob das konfigurierte Kennwort korrekt ist oder nicht, indem Sie sich die Konfiguration ansehen. Um sicherzustellen, dass das Kennwort korrekt ist, wechseln Sie einfach in den Konfigurationsmodus, entfernen und konfigurieren Sie das Kennwort erneut. Um einen Kennwortfehler im Debuggen zu identifizieren, vergleichen Sie die Debugausgabe mit der folgenden Beispielausgabe.
Wenn dieser Router den Peer authentifiziert, stellen Sie sicher, dass Sie den Befehl username username passwordKennwort konfigurieren, wobei Benutzername der Name ist, der vom Peer-Router für die Authentifizierung angegeben wird.
Beispiel 1
Eine Meldung wie die folgende bedeutet, dass das CHAP-Kennwort ungültig ist.
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
Tipp: Ein eingehender CHAP-Fehler (durch CHAP angegeben: FEHLER) bedeutet, dass der Peer den Router nicht authentifizieren konnte. Verwenden Sie Debug-PPP-Aushandlung auf dem Peer-Router, um die genaue Fehlerursache zu bestimmen.
Weitere Informationen finden Sie im Dokument PPP Authentication using the ppp chap hostname and ppp authentication chap callin Commands.
Beispiel 2
Eine Meldung wie die folgende kann bedeuten, dass der CHAP-Benutzername ungültig ist:
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
Tipp: Ein eingehender CHAP-Fehler (durch CHAP angegeben: FEHLER) bedeutet, dass der Peer den Router nicht authentifizieren konnte. Verwenden Sie Debug-PPP-Aushandlung auf dem Peer-Router, um die genaue Fehlerursache zu bestimmen.
Weitere Informationen finden Sie im Dokument PPP Authentication using the ppp chap hostname and ppp authentication chap callin Commands.
Beispiel 3
Eine Meldung wie unten bedeutet, dass das PAP-Kennwort ungültig ist:
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
Weitere Informationen finden Sie im Dokument Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).
Beispiel 4
Eine Meldung wie unten bedeutet, dass der PAP-Benutzername ungültig ist:
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
Weitere Informationen finden Sie im Dokument Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).
Sie können die Cisco Support Community auch zur weiteren PPP-Fehlerbehebung verwenden.
Zurück zum Fehlerbehebungs-Flussdiagramm
Fehlerbehebung: Ist die PPP NCP (IPCP)-Phase abgeschlossen?
Das Schlüsselelement, das in IPCP ausgehandelt wird, ist die Adresse jedes Peers. Vor der IPCP-Aushandlung befindet sich jeder Peer in einem von zwei möglichen Zuständen. entweder über eine IP-Adresse verfügen oder nicht. Wenn der Peer bereits über eine Adresse verfügt, sendet er diese Adresse in einem CONFREQ an den anderen Peer. Wenn die Adresse für den anderen Peer akzeptabel ist, wird ein CONFACK zurückgegeben. Wenn die Adresse nicht akzeptiert werden kann, ist die Antwort ein CONFNAK, der eine Adresse für den Peer enthält.
Dies ist die einzige Phase, die sich nicht anhand einer Zeile identifizieren lässt. Um sicherzustellen, dass das IP Control Protocol (IPCP) ordnungsgemäß funktioniert, müssen Sie überprüfen, ob IP-Adressen in beide Richtungen ausgehandelt wurden. Suchen Sie beim Debuggen nach den folgenden Zeilen:
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
und
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
und
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
Diese drei Linien folgen möglicherweise nicht unmittelbar einander. Es ist wichtig, dass Sie überprüfen, ob eine ausgehende Bestätigung konfigurieren (O CONFACK) vorhanden ist, die unter anderem eine Adresse enthält.
Es muss auch ein eingehendes Konfigurieren bestätigen (I CONFACK) mit einer anderen IP-Adresse darunter vorhanden sein.
Schließlich muss es eine Zeile geben, die besagt, dass der IPCP-Status offen ist. Danach sollten Sie in der Lage sein, beide IP-Adressen direkt vom Router aus zu pingen.
Zurück zum Fehlerbehebungs-Flussdiagramm
Symptom: Die PPP-NCP-Aushandlung (IPCP) ist nicht erfolgreich.
Problem: IP-Adressenverhandlung schlägt fehl
Ein Grund für den Ausfall des IPCP ist ein Fehler bei der IP-Adressverhandlung. Beispielsweise versucht das NAS-Gerät möglicherweise, dem Client eine Adresse zuzuweisen, während der Client-Router eine andere IP-Adresse konfiguriert hat. Ein anderes häufiges Problem ist, wenn der Client eine Adresse anfordert und das NAS keine Adressen für den Client zur Verfügung hat.
Auf dem anrufenden Router:
Wenn der angerufene Router dem anrufenden Router dynamisch eine IP-Adresse zuweist, stellen Sie sicher, dass die Befehl ip address in der Dialer-Schnittstelle ausgehandelt wurde.
Wenn Ihnen der NAS-Provider/ISP eine statische IP-Adresse zugewiesen hat, stellen Sie sicher, dass diese IP-Adresse (und Subnetzmaske) in der Dialer-Schnittstelle mit dem Befehl ip address subnet_mask konfiguriert ist.
Auf dem angerufenen Router:
Stellen Sie sicher, dass die Schnittstelle, die die Verbindung steuert (z. B. int Dialer x), über eine IP-Adresse verfügt und dem Peer mithilfe des Befehls Peer default ip address eine Adresse zuweist.
Hinweis: Wenn auf dem Client-Router eine IP-Adresse konfiguriert ist, müssen Sie mit dem Befehl peer default ip address keine Adresse zuweisen.
Weitere Informationen finden Sie im Dokument Dialup Technology: Fehlerbehebungsverfahren.
Problem: Der angerufene Router schlägt die Dialer-Profilbindung fehl.
Wenn der authentifizierte Benutzername nicht mit dem unter der Dialer-Schnittstelle konfigurierten Remote-Namen des Wählers übereinstimmt, wird der Anruf vom angerufenen Router getrennt. Im Folgenden sehen Sie eine Beispielausgabe für einen Debug-Dialer für einen solchen Fehler:
Auf dem anrufenden Router:
Im folgenden Debugging wird eine Trennung dargestellt, die durch eine fehlerhafte Dialer-Profilbindung des angerufenen Routers verursacht wird.
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
Hinweis: Die Debug-Meldungen auf der angerufenen Seite helfen bei der Behebung dieses Problems nur, um anzuzeigen, dass der Peer den Anruf getrennt hat. Verschieben Sie die Fehlerbehebung zum angerufenen Router.
Auf dem angerufenen Router:
Im folgenden Debugging wird ein Anruf angezeigt, der aufgrund von Dialer-Profilbindungsproblemen fehlschlägt:
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
Lösung:
Konfigurieren Sie den Befehl Dialer-Pool-Nummer auf der Dialer-Schnittstelle. Die Poolnummer muss mit der Poolnummer übereinstimmen, die auf der physischen Schnittstelle konfiguriert wurde.
Konfigurieren Sie den Befehl dialer remote-name auf der Dialer-Schnittstelle. Der angegebene Name muss genau mit dem Benutzernamen übereinstimmen, der vom Remote-Router für die Authentifizierung angegeben wurde. In diesem Beispiel lautet der authentifizierte Benutzername maui-soho-03.
Weitere Informationen zur Fehlerbehebung bei Bindungsproblemen finden Sie im Dokument Konfigurieren und Beheben von Dialerprofilen.
Sie können die Cisco Support Community auch zur weiteren PPP-Fehlerbehebung verwenden.
Zurück zum Fehlerbehebungs-Flussdiagramm
Probleme nach der Verbindung
Symptom: Anruftrennung vorzeitig oder Anruf trennt sich überhaupt nicht
Wenn der Anruf unerwartet beendet wird oder die Verbindung nie unterbrochen wird, überprüfen Sie die Zeitüberschreitung bei Inaktivität des Wählers und die Definition des interessanten Datenverkehrs. Sie können den Befehl debug dialer packet verwenden, um festzustellen, ob ein bestimmtes Paket interessant ist oder nicht. Beispiel:
Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, outgoing uninteresting (list 101) Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes, outgoing interesting (list 101)
Im obigen Beispiel sind die OSPF-Hellos für die Zugriffsliste 101 uninteressant, während das zweite Paket für die Zugriffsliste 101 interessant ist.
- Passen Sie die Leerlaufzeitüberschreitung in der Dialer-Schnittstellenkonfiguration an. Der Standardwert ist 120 Sekunden. Sie können diesen Wert jedoch je nach Ihren Anforderungen erhöhen oder verringern.
- Ändern Sie die interessante Datenverkehrsdefinition (konfiguriert mit dem Befehl dialer-list). Wenn die Verbindung vorzeitig getrennt wird, möchten Sie den interessanten Datenverkehr möglicherweise lockerer definieren. Wenn der Anruf die Verbindung nicht trennt, ändern Sie Ihre Definition des interessanten Datenverkehrs zu restriktiver. Sie können beispielsweise den Routing-Protokoll-Datenverkehr als uninteressant definieren. Hier ein Beispiel für eine interessante Verkehrsdefinition:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1Weitere Informationen finden Sie im Dokument Dialup Technology: Übersichten und Erklärungen.
Symptom: Der Router wählt die Verbindung regelmäßig.
In bestimmten Situationen können Sie feststellen, dass der Router regelmäßig die Verbindung wählt, obwohl kein sichtbarer Benutzerdatenverkehr die Verbindung aktiv machen muss. Dies kann zu hohen Mautgebühren führen, wenn ISDN-Dienste pro Minute berechnet werden.
Die häufigste Ursache ist, dass ein Prozess, der periodischen Datenverkehr generiert (z. B. Routing-Protokoll, NTP, SNMP usw.) versehentlich als interessant bezeichnet wird. Die Behebung dieses Problems erfolgt in zwei Schritten:
- Identifizieren Sie den Datenverkehr, der die Verbindung zum Wählen verursacht.
- Bestimmen Sie diesen Datenverkehr als uninteressant.
Identifizieren Sie den Datenverkehr, der die Verbindung zum Wählen verursacht.
Um den Datenverkehr zu identifizieren, der die Verbindung zum Wählen verursacht, müssen Sie das Debug Dialer-Paket aktivieren. Überwachen Sie den Router, während die ISDN-Verbindung nicht verfügbar ist, und achten Sie auf einen periodischen interessanten Datenverkehr, der versucht, die Verbindung aufzurufen.
Tipp: Weisen Sie, sofern nicht ausdrücklich erforderlich, alle auf dem Router konfigurierten Routing-Protokolle als uninteressant zu.
Das folgende Beispiel zeigt, dass periodische OSPF-Hellos als interessant gekennzeichnet werden:
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
Die einzige Möglichkeit, festzustellen, dass es sich bei dem oben genannten Paket um ein OSPF-Hello handelt, ist die Zieladresse (d=224.0.0.5), die für OSPF definiert ist. In der folgenden Tabelle sind die Adressen aufgeführt, die für einige gängige Routing-Protokolle verwendet werden:
|
Routing-Protokoll
|
Zieladresse für periodische Updates oder Keepalives |
|
RIPv1
|
255 255 255 255 255
|
|
RIPv2
|
224,0,0,9
|
|
EIGRP
|
224,0,0,10
|
|
OSPF
|
224,0,0,5
|
Der Datenverkehr, der den Router zum Wählen veranlasst (Routing-Protokoll oder anderer regelmäßiger Datenverkehr) sollte als uninteressant gekennzeichnet werden.
Den periodischen Datenverkehr als uninteressant festlegen
Ändern Sie die interessante Datenverkehrsdefinition (konfiguriert mit dem Befehl dialer-list). In diesem Beispiel definieren Sie OSPF- und NTP-Datenverkehr als uninteressant. Hier ein Beispiel für eine interessante Verkehrsdefinition:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
Weitere Informationen finden Sie im Dokument Dialup Technology: Übersichten und Erklärungen.
Hinweis: OSPF verfügt über eine Funktion namens "Demand Circuit", die auch hier verwendet werden kann. Weitere Informationen finden Sie im Dokument Why OSPF Demand Circuit Keeps Bringing the Link for more information.
Symptom: Zweiter B-Kanal stellt keine Verbindung her
In vielen Fällen kann der Router nur eine Verbindung mit einem B-Kanal herstellen, während der andere B-Kanal im Leerlauf bleibt. Weitere Informationen zur Behebung dieses Problems finden Sie im Dokument Troubleshooting Second B-channel Call Failures (Zweite B-Kanal-Anrufausfälle) auf ISDN BRI-Links.
IP-Verbindungsprobleme
Wenn die ISDN-Verbindung aktiv ist, der Datenverkehr aber nicht über die Verbindung weitergeleitet werden kann, handelt es sich wahrscheinlich um ein Routing- oder ein NAT-Problem. Weitere Informationen zur Fehlerbehebung finden Sie in der Cisco Support Community.
Wenn Sie den ISDN-Link als Backup einer WAN-Verbindung verwenden, lesen Sie das Dokument Konfiguration und Fehlerbehebung bei DDR-Sicherung.
Zugehörige Informationen
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)