Fehlerbehebung für ISDN BRI Layer 3 mit dem Befehl debug isdn q931

Einführung

Bei der Behebung von Problemen mit ISDN-Anrufen ist zu beachten, dass der Anruf aufgrund einer der folgenden Faktoren möglicherweise fehlschlägt:

• Dial-on-Demand-Routing (DDR)

• ISDN-Layer 1, 2 und 3

• Point-to-Point Protocol (PPP): einschließlich Verbindungsprotokoll (LCP), Authentifizierungs- oder IP Control Protocol (IPCP)-bezogene Probleme.

Dieses Dokument konzentriert sich speziell auf ISDN-bezogene Probleme, die Anrufausfälle verursachen. In diesem Dokument wird außerdem davon ausgegangen, dass Sie überprüft haben, ob die ISDN-Layer 1 und 2 an beiden Enden der Leitung funktionieren. Weitere Informationen zur Überprüfung des Status von ISDN Layer 1 und 2 finden Sie unter show isdn status Command for BRI Troubleshooting.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

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

Konventionen

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

Voraussetzungen für die Fehlerbehebung: Aktivieren von ISDN-Layer-3-Debuggen

Verwenden Sie den Befehl debug isdn q931 an beiden Enden, um ISDN-Layer-3-Debugger zu aktivieren. Außerdem sollten auf beiden Routern Zeitstempel in Millisekunde für das Debuggen aktiviert sein. Die Zeitstempel sind erforderlich, um eine relative Eingabe für den Fehlerbehebungsprozess bereitzustellen.

Hinweis: Aktivieren Sie mithilfe der folgenden Befehle Zeitstempel in Millisekunden für das Debuggen:

maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec

Weitere Informationen zu Debugbefehlen finden Sie unter Wichtige Informationen über Debug-Befehle.

ISDN-Anruf initiieren

Generieren Sie einen ICMP-Ping an die IP-Adresse des Remote-Routers. Dadurch sollte ein ISDN-Anruf an diesen Router initiiert werden. Beide Router generieren debug isdn q931-Meldungen.

Die Q.931-Austauschmodule können aufgrund spezifischer Anforderungen an ISDN-Switch-Typen oder in Fällen, in denen zusätzliche Parameter erforderlich sind, viele Variationen aufweisen. Das folgende Diagramm zeigt die allgemeinen Q.931-Transaktionen bei einer erfolgreichen ISDN-Anrufeinrichtung.

Hinweis: Einige der folgenden Zeilen in der Debugausgabe werden zu Druckzwecken in mehrere Zeilen unterteilt.

maui-soho-01#
18:39:29.425: ISDN BR0: TX -> SETUP
    pd = 8  callref = 0x10

!-- The Calling Router Transmits !-- (indicated by TX) the SETUP message

18:39:29.433:
         Bearer Capability i = 0x8890
18:39:29.441: Channel ID i = 0x83
18:39:29.449:
         Keypad Facility i = '5558888'
18:39:29.822: ISDN BR0: RX <- CALL_PROC
    pd = 8  callref = 0x90

!-- The telco switch responds with a !-- Call Proceeding. This indicates the !-- network is processing the call.

18:39:29.830:
         Channel ID i = 0x89
.
.
.

!-- Nothing has been omitted here. The !-- dots were put in place to align !-- the Called and Calling Routers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18:39:30.000: ISDN BR0: RX <- CONNECT
    pd = 8  callref = 0x90

!-- Received a CONNECT from the remote !-- router. The ISDN connection has been !-- established. Any failures of the call !-- past this point are due to higher !-- level issues such as DDR, PPP, !-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK
    pd = 8  callref = 0x10

!--- The Router responds with a Connect !--- Acknowledgment (CONNECT_ACK) !--- to the telco.

maui-nas-08#
18:39:29.647: ISDN BR2/0: RX <- SETUP
    pd = 8  callref = 0x08

!-- The Called Router receives !-- (indicated by RX) a SETUP message !-- from the switch

18:39:29.647:
    Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital. 

18:39:29.647: Channel ID i = 0x89
18:39:29.647:
    Signal i = 0x40 - Alerting on -
    pattern 0 
18:39:29.647:
    Called Party Number i = 0xC1,'5558888',
    Plan:ISDN, Type:Subscriber(local)
18:39:29.647:
    Locking Shift to Codeset 5
18:39:29.647:
    Codeset 5 IE 0x2A  
    i = 0x808001038001118001, '<'
18:39:29.651:
    ISDN BR2/0: Event: Received a DATA 
    call from  on B1 at 64 Kb/s
18:39:29.651: ISDN BR2/0: TX -> CALL_PROC
    pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding
 
18:39:29.655:
         Channel ID i = 0x89
18:39:29.655: %LINK-3-UPDOWN:
 Interface BRI2/0:1, changed state to up
18:39:29.955: ISDN BR2/0: TX -> CONNECT
    pd = 8  callref = 0x88

!--- Call is accepted and the routers sends !--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89
18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK
    pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK !--- from the switch

18:39:29.995:
         Channel ID i = 0x89
18:39:29.995:
         Signal i = 0x4F - Alerting off 
18:39:35.655: %ISDN-6-CONNECT:
 Interface BRI2/0:1 is now
 connected to unknown 

Beachten Sie bei der Auswertung der debug isdn q931-Ausgabe an den aufrufenden und angerufenen Enden die folgenden Punkte:

• Achten Sie auf die Richtung der Nachrichten. Die Debug-Meldungen geben an, ob die Meldungen vom Router generiert wurden (durch TX -> gekennzeichnet) oder ob sie vom Router empfangen wurden (durch RX <— gekennzeichnet). Im folgenden Beispiel wird die erste Meldung (CONNECT) vom Router vom ISDN-Switch empfangen, die zweite (CONNECT_ACK) wird vom Router gesendet:

  18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90
  18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10
  
  

  Sie können die Ursache des Problems ermitteln, indem Sie die Richtung einer bestimmten Meldung und der Antwort befolgen. Erhält der Router beispielsweise unerwartet eine RELEASE-Nachricht vom telco ISDN-Switch, setzt er auch das Ende der Verbindung zurück. Dies weist darauf hin, dass das Problem beim telco ISDN-Switch oder beim Remote-Router liegt.

• Stellen Sie sicher, dass die erhaltene oder gesendete Nachricht die erwartete ist. Wenn der angerufene Teilnehmer beispielsweise eine SETUP-Nachricht empfängt, aber eine DISCONNECT anstatt CONNECT sendet, führen Sie eine Fehlerbehebung für den angerufenen Router durch, und nicht für das ISDN-Netzwerk. Die folgende Tabelle enthält eine Liste möglicher Q.931-Nachrichten, die während der Einrichtung und Beendigung von Anrufen angezeigt werden:

Fehlerbehebung im Überblick: Symptom- und Auflösungsverfahren

Analysieren Sie die Ausgabe debug isdn q931 wie in den vorherigen Abschnitten beschrieben, und fahren Sie mit dem entsprechenden Symptom fort, das unten beschrieben wurde.

Hinweis: In diesem Dokument wird der Router, der den Anruf initiiert, als anrufender Router bezeichnet, während der Router, der den Anruf annimmt, als angerufener Router bezeichnet wird.

Fehlerbehebung: Symptom und Detailliertes Auflösungsverfahren

Der anrufende Router sendet keine SETUP-Meldung

Wenn der anrufende Router keine SETUP-Nachricht an das ISDN-Netzwerk sendet, ist das Problem wahrscheinlich mit Problemen im Zusammenhang mit ISDN-Layern 1, 2 oder Dial-on-Demand Routing (DDR) verbunden und nicht mit Problemen im Zusammenhang mit Layer 3.

Führen Sie die folgenden Aufgaben auf dem anrufenden Router aus:

• Stellen Sie sicher, dass der ISDN-Switchtyp korrekt konfiguriert ist:

  Der ISDN-Switch kann mit dem Befehl show isdn status überprüft werden. Der Telekommunikationsanbieter sollte explizit den zu konfigurierenden Switch-Typ angeben. Gelegentlich (insbesondere in Nordamerika) kann das Telco angeben, dass der Switchtyp "benutzerdefiniert" oder "national" ist. Verwenden Sie in solchen Fällen die folgenden Richtlinien, um die Switch-Typ-Konfiguration zu bestimmen:

  • Benutzerdefiniert: Wenn das Telco anzeigt, dass der Switch-Typ "Benutzerdefiniert" ist, konfigurieren Sie den Switchtyp auf dem Router als Basic-5ess (für BRI mit 5-ess-Switch), als Primär-5ess (für PRI mit 5-ess), als Basis-DMS (für BRI mit DMS-Switch) oder als Primär-DMS (für PRI mit DMS).

  • National: Der Switch-Typ entspricht dem NI-1-Standard für BRI und NI-2-Standard für PRI (es gibt keinen NI-1-Standard für PRIs). Wenn Ihnen das Telco mitteilt, dass der Switch National ist, sollte die Konfiguration des Cisco Routers Basic-in (für BRI) oder Primary-NI (für PRI) sein.

  Zur Konfiguration des Switch-Typs verwenden Sie den Befehl isdn-switch-type switch-type im BRI-Schnittstellenkonfigurationsmodus. Ein Beispiel finden Sie unter Fehlerbehebung für ISDN BRI Layer 1.

• Überprüfen Sie, ob die ISDN-Layer 1 und 2 auf dem anrufenden Router funktionieren:

  Sie können mithilfe des Befehls show isdn status überprüfen, ob die ISDN-Layer 1 und 2 aktiviert sind. Gehen Sie wie in beschrieben vor, um Probleme im Zusammenhang mit ISDN Layer 1 und 2 zu beheben.

• Verwenden Sie den Befehl show ip route, um zu überprüfen, ob der Router eine Route zum Ziel hat.

  Der Befehl show ip route gibt an, ob eine Route zum Netzwerk des Remote-Routers vorhanden ist. Wenn die Route nicht vorhanden ist, können Sie mit dem Befehl ip route eine statische Route für das Remote-Netzwerk hinzufügen. Stellen Sie sicher, dass die Route zur richtigen Schnittstelle auf dem anrufenden Router zeigt.

  In einer älteren DDR-Umgebung (z. B. Dialer-Maps) sollte der nächste Hop entweder das physische Schnittstellennetzwerk (Interface BRI x) oder die IP-Adresse des Remote-Routers (die ebenfalls in der Dialer-Map-Anweisung konfiguriert werden sollte) sein.

  Bei Dialer-Profilen ist der nächste Hop normalerweise die Schnittstelle Dialer x, die für das Wählen verwendet wird. Beispiel:

  maui-soho-01#show ip route
  ...
  ...
  !-- Output omitted
  
  ...
  
       10.0.0.0/24 is subnetted, 1 subnets
  C       10.0.0.0 is directly connected, Ethernet0
  S*   0.0.0.0/0 is directly connected, Dialer1
  

  Beachten Sie im obigen Beispiel, dass die Standardroute Next Hop die Schnittstelle Dialer 1 ist (die logische Dialer-Schnittstelle für diese Verbindung).

• Stellen Sie sicher, dass der interessante Datenverkehr korrekt identifiziert wurde.

  Der Router überprüft vor dem Einleiten des Wählvorgangs, ob es sich bei einem eingehenden Paket um einen interessanten Datenverkehr handelt. Daher kann der Router nicht wählen, wenn der interessante Datenverkehr falsch definiert ist oder wenn die Wähllistennummer (die interessante Datenverkehrsdefinition) nicht auf die physische oder Dialer-Schnittstelle angewendet wird (mit dem Befehl Dialer-Gruppe-Nummer). Wenn Sie beispielsweise einen ICMP-Ping verwenden, um die DDR-Verbindung zu initiieren, stellen Sie sicher, dass der ICMP in der interessanten Datenverkehrsdefinition zulässig ist.

  Weitere Informationen finden Sie unter Konfigurieren von BRI-to-BRI-Dialup mit DDR-Dialer-Karten.

• Überprüfen Sie, ob die entsprechende Wählzeichenfolge (oder Wählerübersicht) die ISDN-Nummer des Remote-Geräts enthält.

  Die Wählerzeichenfolge (oder Wählerzuordnung) muss die ISDN-Nummer des Remote-Routers enthalten. Beispiel:

  dialer string 5551111
  or
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  

• Überprüfen Sie die DDR-Konfiguration, und verwenden Sie den Debug Dialer, um zu überprüfen, ob der Router den Anruf initiiert:

  Überprüfen Sie, ob die DDR-Konfiguration korrekt ist. Verwenden Sie das Dokument Dialup Technology: Übersichten und Erklärungen für weitere Unterstützung bei der richtigen DDR-Konfiguration.

  Sie sollten auch den Befehl debug dialer verwenden, um zu überprüfen, ob der Router interessanten Datenverkehr empfängt und über die entsprechende Dialer-Map oder Dialer-Zeichenfolge verfügt, um die Wählverbindung zu initiieren. Weitere Informationen finden Sie im obigen Dokument sowie in der DFÜ-Technologie: Fehlerbehebungsverfahren für weitere Informationen.

  Beispiele für eine ordnungsgemäße DDR-Konfiguration finden Sie in der folgenden Beispielkonfiguration:

  Dialer-Profile: Konfigurieren von ISDN DDR mit Dialer Profiles Legacy DDR(Dialer Maps): Konfigurieren von BRI-to-BRI-Dialup mit DDR-Dialer-Karten

  Tipp: Zu Testzwecken können Sie DDR eliminieren, indem Sie mit dem Befehl isdn call (im nächsten Abschnitt erläutert) einen ISDN-Anruf für das Remote-Gerät generieren. Wenn dieser Anruf erfolgreich ist, können Sie sich einigermaßen sicher sein, dass die ISDN-Leitung funktioniert. Setzen Sie die Fehlerbehebung für DDR fort.

• Durchführen eines Loopback-Testanrufs

  Bei einem Loopback-Anruf wählt der Router die ISDN-Nummer seines eigenen BRI. Der Anruf geht in die Telco-Cloud weiter, wo der Telco den Anruf an den zweiten BRI-Kanal weiterleitet. Dieser Anruf wird nun vom Router als eingehender Anruf auf dem zweiten Kanal angesehen. Daher sendet und empfängt der Router den ISDN-Anruf.

  Bei einem Loopback-Anruf wird die Fähigkeit des Routers getestet, einen ISDN-Anruf zu initiieren und zu beenden. Ein erfolgreicher Loopback-Anruf gibt Ihnen einen deutlichen Hinweis darauf, dass die ISDN-Leitung zur Telco-Cloud ordnungsgemäß funktioniert.

  Im Folgenden sehen Sie ein kommentiertes Beispiel für einen erfolgreichen Loopback-Anruf. Der Befehl isdn call (eingeführt in Cisco IOS® Software 12.0(3)T) ermöglicht ausgehende Anrufe, ohne dass die DDR-Anforderungen wie interessanter Datenverkehr und Routen erforderlich sind. Dieser Befehl kann nur zum Testen der ISDN-Leitung verwendet werden und kann nicht zum Übergeben von Datenverkehr oder als Ersatz für eine ordnungsgemäße DDR-Konfiguration verwendet werden. Mit diesem Befehl können wir überprüfen, ob die ISDN-Schaltung, insbesondere Layer 3, funktioniert.

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: 
Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: 
Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful

Hinweise:

• Während des Loopback-Anrufs fungiert der Router sowohl als angerufener Router als auch als anrufender Router (wenn auch auf unterschiedlichen B-Kanälen). Es ist wichtig, dass Sie diese "doppelten Rollen" beim Interpretieren der debug isdn q931-Ausgabe verfolgen. Beispielsweise überträgt der Router eine Setup-Meldung (TX -> SETUP) und empfängt auch eine Nachricht (RX <- SETUP). Das übertragene SETUP sollte dem ausgehenden Anruf zugeordnet werden, während die empfangene SETUP-Nachricht dem eingehenden Anruf zugeordnet ist.

• Im obigen Beispiel haben wir die Nummer für den ersten B-Kanal gewählt. Der Telco erkannte jedoch, dass der erste B-Kanal belegt war (seit er den Anruf getätigt hatte), wechselte den Anruf zum zweiten B-Kanal, und die Verbindung wurde erfolgreich hergestellt. Eine Fehlkonfiguration des Telco-Switches kann jedoch zum Ausfall des Loopback-Anrufs führen, da der Switch versucht, den Anruf dem ersten Kanal zuzuweisen (der gerade mit dem Anruf beschäftigt ist). Der Telekommunikationsanbieter sollte dieses Problem beheben. Als Problemumgehungslösung muss jedoch die zweite B-Channel-Nummer im Befehl isdn angegeben werden.

• Wenn der Loopback-Anruf erfolgreich ist und der Anruf am Remote-Ende weiterhin fehlschlägt, wenden Sie sich an den Telco, um weitere Unterstützung bei der Fehlerbehebung für Ihren BRI-Schaltkreis zu erhalten.

Der angerufene Router erhält keine SETUP-Meldung.

Wenn Sie feststellen, dass der anrufende Router eine ISDN-Layer-3-SETUP-Nachricht sendet, diese jedoch nicht vom angerufenen Router empfangen wird, kann es sich um ein Problem mit den ISDN-Ebenen 1 und 2 auf dem angerufenen Router handeln, oder es kann sich um ein Problem mit der telco-ISDN-Cloud handeln.

Führen Sie die folgenden Aufgaben auf dem angerufenen Router aus:

• Stellen Sie sicher, dass der ISDN-Switchtyp korrekt konfiguriert ist:

  Der ISDN-Switch kann mit dem Befehl show isdn status überprüft werden. Der Telekommunikationsanbieter sollte explizit den zu konfigurierenden Switch-Typ angeben. Gelegentlich (insbesondere in Nordamerika) kann das Telco angeben, dass der Switchtyp "benutzerdefiniert" oder "national" ist. Verwenden Sie in solchen Fällen die folgenden Richtlinien, um die Switch-Typ-Konfiguration zu bestimmen:

  • Benutzerdefiniert: Wenn das Telco anzeigt, dass der Switch-Typ "Benutzerdefiniert" ist, konfigurieren Sie den Switchtyp auf dem Router als Basic-5ess (für BRI mit 5-ess-Switch), Primary-5ess (für PRI mit 5-ess), Basic-dms (für BRI mit DMS-Switch) oder Primary-DMS (für PRI mit DMS).

  • National: Der Switch-Typ entspricht dem NI-1-Standard für BRI und NI-2-Standard für PRI (es gibt keinen NI-1-Standard für PRIs). Wenn Ihnen das Telco mitteilt, dass der Switch National ist, sollte die Konfiguration des Cisco Routers Basic-in (für BRI) oder Primary-NI (für PRI) sein.

  Zur Konfiguration des Switch-Typs verwenden Sie den Befehl isdn-switch-type switch type im BRI-Schnittstellenkonfigurationsmodus. Ein Beispiel finden Sie unter Fehlerbehebung für ISDN BRI Layer 1.

• Überprüfen Sie, ob die ISDN-Layer 1 und 2 auf dem anrufenden Router funktionieren:

  Sie können mithilfe des Befehls show isdn status überprüfen, ob die ISDN-Layer 1 und 2 aktiviert sind. Verwenden Sie zur Fehlerbehebung bei Problemen im Zusammenhang mit ISDN Layer 1 und 2 das Verfahren unter Verwenden des Befehls show isdn status for BRI Troubleshooting (Befehl zum Anzeigen des ISDN-Status bei der Fehlerbehebung).

• Überprüfen der korrekten Konfiguration der SPID Local Directory Number (LDN)

  Bestimmte Switchtypen erfordern eine korrekte Konfiguration von Spid und Ldn, damit eingehende Anrufe angenommen werden können. Weitere Informationen finden Sie unter Problembehandlung bei ISDN BRI SPIDs.

Führen Sie die folgenden Aufgaben auf dem anrufenden Router aus:

• Verwenden Sie ein reguläres analoges Telefon, um einen Testanruf beim Remote-Router zu tätigen.

  Wählen Sie mit einem normalen analogen Telefon die ISDN-Nummer des angerufenen Routers genau so, wie sie auf dem anrufenden Router konfiguriert ist. Der angerufene Router sollte eine SETUP-Meldung erhalten (obwohl der Anruf später fehlschlägt, da es sich nicht um einen ISDN-Anruf handelt). Wenn der angerufene Router die SETUP-Nachricht empfängt, können wir davon ausgehen, dass das ISDN-Netzwerk der angerufenen Seite funktioniert. Das Problem kann das lokale ISDN-Netzwerk, die Ziel-ISDN-Nummer, der Ferndienst usw. sein. Fahren Sie mit den Schritten unten fort.

• Stellen Sie sicher, dass die Ziel-ISDN-Nummer richtig konfiguriert ist:

  Überprüfen Sie die Konfiguration des anrufenden Routers, und überprüfen Sie, ob die für den Remote-Router konfigurierte ISDN-Nummer korrekt ist. Oft erfordern ISDN-Schaltungen hinter einem PBX-System eine 9 vor der ISDN-Nummer. Wenn es sich bei dem Anruf um einen Ferngespräch handelt (in den USA), sollten Sie die Ziffer 1 vor der ISDN-Nummer des Remote-Standorts angeben (ähnlich wie bei normalen Ferngesprächen). Stellen Sie sich beispielsweise eine Situation vor, in der sich der lokale Standort hinter einem PBX-System befindet und der Anruf an den Remote-Standort ein Ferngespräch sein muss. Die ISDN-Nummer für das Remote-Ende lautet 5551111 innerhalb der Ortsvorwahl 512. In diesem Fall, einschließlich der entsprechenden Ziffern für das PBX-System und für Ferngespräche, ist die gewählte Nummer 915125551111.

  Der Grund debug isdn q931 disconnect kann auch verwendet werden, um festzustellen, ob der Anrufausfall auf eine falsche Remote-ISDN-Nummer oder eine falsch formatierte Nummer zurückzuführen ist. Weitere Informationen zum Interpretieren von Ursachencodes für die Trennung von ISDN q931 finden Sie im Dokument Understanding isdn q931 Disconnect Cause Codes (Erläuterungen zum Debuggen).

  Eine Verbindungstrennung aufgrund einer falschen ISDN-Nummer kann angezeigt werden mit:

  Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85
  Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination
  

  Mit Bezug auf das zuvor erwähnte Dokument für Trennungsursachencodes können wir feststellen, dass der Trennungscode durch den Versuch verursacht wurde, eine Verbindung zu einem Nicht-ISDN-Gerät herzustellen. (Beispiel: eine analoge Leitung.)

  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)
  

  Im Dokument Understanding debug 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.

• Prüfen Sie ggf., ob der Fernservice aktiv ist:

  Wenden Sie sich an Ihren lokalen Telekommunikations- und Fernanbieter, um zu überprüfen, ob der Service aktiviert ist. Häufig ist der ISDN-Circuit im lokalen Telco so falsch konfiguriert, dass ausgehende ISDN-Ferngespräche nicht an das entsprechende Fern-Distance-Provider-Netzwerk umgeleitet werden. Sie sollten auch überprüfen, ob das Netzwerk der Fernanbieter funktioniert.

  In den USA und in Situationen, in denen der Fernmeldeanbieter das Problem nicht beheben kann, können Sie einen vorab angemeldeten Austauschträger (PIC) verwenden. PIC-Codes sind 7-stellige Präfixe, die US-Fernnetzbetreiber mit den lokalen Börsenbetreibern (LEC) identifizieren. So können Kunden für separate Anrufe verschiedene Festnetzbetreiber verwenden. Der PIC-Code wird als Präfix für die gewählte Nummer konfiguriert. Die meisten PICs haben das Format 1010xxx. Eine numerische Liste der PICs finden Sie unter US PIC-Codes, numerisch

• Konfigurieren Sie zwei Dialer-Zuordnungen oder zwei Dialer-Zeichenfolgenanweisungen. eine für die ISDN-Nummer jedes Remote-B-Kanals:

  Durch die Konfiguration einer Dialer-Map (oder einer Dialer-Zeichenfolge, wenn Dialer-Profile verwendet werden) für jeden Remote-B-Kanal kann die Verbindung fortgesetzt werden, selbst wenn der Telco nicht in der Lage ist, den zweiten Anruf auf den zweiten ISDN B-Kanal umzuleiten.

  Hinweis: Diese Problemumgehung ist erforderlich, wenn nur ein B-Kanal Anrufe auf einem bestimmten BRI annimmt. Dieses Problem tritt häufig bei Multilink-Verbindungen auf.

  Eine Beispielkonfiguration (mithilfe von Dialer Maps) wird bereitgestellt:

  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112
  
  !--- dialer map statements for the remote router !--- The two different phone numbers correspond !--- to the b-channels of the remote side. The multiple statements allow !--- the router to dial the second number if the first number is busy. 
  
  

Der angerufene Router sendet keine CONNECT-Nachricht.

Wenn der angerufene Router eine SETUP-Nachricht empfängt, aber nicht mit einer CONNECT-Nachricht antwortet, kann dies darauf hinweisen, dass der Router (aus einem unbestimmten Grund) den Anruf nicht annimmt.

Führen Sie die folgenden Aufgaben auf dem angerufenen Router aus:

• Überprüfen Sie, ob der Anruf aufgrund einer Screening-Prüfung auf Anrufer-ID/DNIS-Basis abgelehnt wurde:

  Die Anrufer-ID oder DNIS-basierte Überprüfung ermöglicht es dem Router, bestimmte Anrufe ohne anfallende Gebühren selektiv anzunehmen oder abzulehnen. Beim Screening auf Basis der Anrufer-ID erhält der angerufene Router (in der SETUP-Nachricht) die Nummer des anrufenden Teilnehmers. Auf diese Weise kann der Router Anrufe von bestimmten Nummern zulassen und bietet so ein gewisses Maß an Sicherheit. Durch die DNIS-basierte Überprüfung werden eingehende Anrufe vom angerufenen Router anhand der gewählten Nummer unterschieden.

  Hinsichtlich der CLID/DNIS-basierten Screening-Funktionen sind einige wichtige Punkte zu beachten:

  1) Das Telco muss die entsprechenden CLID/DNIS-Informationen in der SETUP-Nachricht bereitstellen. Wenn Sie die Anrufer-ID-Screening auf dem Router aktivieren, aber keine Anrufer-ID-Nummern an den Router übergeben haben, werden alle Anrufe an den Router "überprüft", und es werden keine Anrufe angenommen.

  2) Überprüfen Sie das Format der vom telco bereitgestellten CLID/DNIS-Ziffern (in der debug isdn q931-Ausgabe). Beispielsweise enthalten einige Telekommunikationsanbieter den Ortscode in den gelieferten CLID/DNIS-Ziffern, andere nicht. Korrigieren Sie ggf. alle CLID/DNIS-Konfigurationen.

  Im Folgenden sehen Sie ein Beispiel für einen fehlgeschlagenen Anruf. Auf dem Router ist CLID-basiertes Screening aktiviert. Da das Telco die CLID-Ziffern jedoch nicht bereitstellt, lehnt der Router den Anruf ab.

  maui-nas-08#
  05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E
  
  ! --- The router receives (RX) a SETUP message
  
  05:46:33:         Bearer Capability i = 0x8890
  05:46:33:         Channel ID i = 0x89
  05:46:33:         Signal i = 0x40 - Alerting on - pattern 0 
  05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,
    Type:Subscriber(local)
  
  ! --- The Called Number (DNIS) is delivered to the router ! --- Note that CLID information is not delivered
  
  05:46:33:         Locking Shift to Codeset 5
  05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
  05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE
  05:46:33:         Cause i = 0x8095 - Call rejected
  
  ! --- Calls is Rejected due to screening
  
  

  Weitere Informationen zur Anrufer-ID finden Sie im Dokument ISDN-Authentifizierung und Rückruf mit Anrufer-ID.

• Überprüfen Sie, ob die SPIDs korrekt sind:

  Verwenden Sie den Befehl show isdn status, um zu überprüfen, ob die SPIDs auf dem angerufenen Router korrekt sind. Weitere Informationen zur Behebung von Problemen mit der Spid finden Sie unter show isdn status Command for BRI Troubleshooting.

• Stellen Sie sicher, dass in dem gewählten Stromkreis B-Kanäle verfügbar sind:

  Mit dem Befehl show isdn status können Sie überprüfen, ob in der gewählten Leitung Kanäle verfügbar sind. Wenn keine Kanäle verfügbar sind, können Sie den Befehl clear verwenden, um einige Kanäle freizugeben.

• Wenn mehrere BRIs verfügbar sind, lassen Sie diese vom Telco in einem Sammelanschluss konfigurieren:

  Wenn mehrere BRIs in einer Sammelanschlussgruppe vorhanden sind, kann der Telekommunikationsanbieter den Anruf auf einen beliebigen freien BRI-Schaltkreis des Routers umschalten. Wenden Sie sich für diese Funktion an den Telekommunikationsanbieter.

• Überprüfen Sie, ob bei Ihnen Probleme im Zusammenhang mit der Trägerfunktion auftreten:

  Die Trägerleistung (oder Träger-Cap) ist die Layer-3-Dienstanzeige, die die Merkmale eines bestimmten Anrufs definiert. Die Träger-Obergrenze eines Anrufs wird in den Q.931-SETUP-Nachrichten durch telco angegeben. Die Träger-Kappe wird häufig verwendet, um zwischen 64.000 Sprach- (analogen), 56.000 Datenanrufen und 64.000 Datenanrufen zu unterscheiden. Nachfolgend sind die am häufigsten zu hörenden Trägerverschlüsse und ihre Beschreibungen aufgeführt:

  Träger-Kap	Beschreibung
  0 x 8890	ISDN 64K-Anruf
  0 x 8890218F	ISDN 56K-Anruf
  0x8090A2	Sprach-/Sprachanruf (u-law)
  0x9090A2	Sprach-/Sprachgespräch (u-law) - 3,1 kHz Audio
  0 x 8090A3	Sprach-/Sprachgespräch (A-law)
  0 x 9090 A3	Sprach-/Sprachgespräch (A-law) - 3,1 kHz Audio

  Im Folgenden sehen Sie ein Beispiel für einen ISDN 64k-Anruf:

  Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F
  
  !-- Incoming SETUP messages
  
  Aug  8 18:49:48.246:         Bearer Capability i = 0x8890
  
  !-- The bearer cap indicates the incoming call is ISDN 64k
  
  Aug  8 18:49:48.246:         Channel ID i = 0x89......
  

  Führen Sie je nach Träger-Kappe des Anrufs die folgenden Schritte aus:

  Träger-Kapazität ist 0x890218F: Der Anruf ist ISDN 56K digital:

  • Stellen Sie sicher, dass der ISDN-Switchtyp korrekt konfiguriert ist:

    Der ISDN-Switch kann mit dem Befehl show isdn status überprüft werden. Der Telekommunikationsanbieter sollte explizit den zu konfigurierenden Switch-Typ angeben. Gelegentlich (insbesondere in Nordamerika) kann das Telco angeben, dass der Switchtyp "benutzerdefiniert" oder "national" ist. Verwenden Sie in solchen Fällen die folgenden Richtlinien, um die Switch-Typ-Konfiguration zu bestimmen:

    • Benutzerdefiniert: Wenn das Telco anzeigt, dass der Switch-Typ "Benutzerdefiniert" ist, konfigurieren Sie den Switchtyp auf dem Router als Basic-5ess (für BRI mit 5-ess-Switch), Primary-5ess (für PRI mit 5-ess), Basic-dms (für BRI mit DMS-Switch) oder Primary-DMS (für PRI mit DMS).

    • National: Der Switch-Typ entspricht dem NI-1-Standard für BRI und NI-2-Standard für PRI (es gibt keinen NI-1-Standard für PRIs). Wenn Ihnen das Telco mitteilt, dass der Switch National ist, sollte die Konfiguration des Cisco Routers Basic-in (für BRI) oder Primary-NI (für PRI) sein.

    Zur Konfiguration des Switch-Typs verwenden Sie den Befehl isdn-switch-type switch type im BRI-Schnittstellenkonfigurationsmodus. Ein Beispiel finden Sie unter Fehlerbehebung für ISDN BRI Layer 1.

  • Stellen Sie auf der Wählseite sicher, dass die Geschwindigkeit/Geschwindigkeit des Anrufs 56.000 beträgt. Dies ist erforderlich, da einige ältere ISDN-Switches möglicherweise nicht den Clear Channel übergeben und Sie zwingen können, einen Anruf mit 56.000 zu tätigen, um den Anruf zu erhalten.

    Verwenden Sie den Speed-Parameter im Konfigurationsbefehl Dialer Map, um ausgehende Anrufe mit 56 Kbit/s durchzuführen, wie im folgenden Beispiel gezeigt:

    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 5551111
    
    !-- The keyword speed 56 sets the outgoing call rate at 56k
    
    

    Im folgenden Beispiel wird veranschaulicht, wie ein Cisco IOS-Wählprofil so konfiguriert wird, dass ausgehende Anrufe mit 56 Kbit/s getätigt werden:

    maui-soho-01(config)#interface dialer 1
    maui-soho-01(config-if)#dialer string 5558888 class 56k     
    
    !-- Use the map-class named "56k" when dialing number 5558888 
               
    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 above
    
    maui-soho-01(config-map-clas)#dialer isdn speed 56
    
    !-- Set the speed of the call to be 56k (default is 64k)
    
    

  • Konfigurieren Sie auf der Empfängerseite den Befehl isdn not-end-to-end 56 unter der BRI-Schnittstelle.

    Maui-NAS-08(config)#interface bri 2/0
    Maui-NAS-08(config-if)#isdn not-end-to-end 56
    

    Die ISDN Q.931-Trägerfunktion und andere Informationselemente (IE) dienen zur Bestimmung der Geschwindigkeit des eingehenden Anrufs und funktionieren in den meisten Fällen ordnungsgemäß. In einigen Anwendungen, die von Land zu Land ausgeführt werden (oder aufgrund von Legacy-Switches), wird die Einrichtungsnachricht für eingehende Anrufe jedoch mit einer Trägerfunktion übermittelt, die nicht mit dem ursprünglichen Anruf übereinstimmt. Wenn eine Meldung mit der Angabe "Nicht End-to-End" empfangen wird, kann der Router die empfangene Trägerfunktion mithilfe des Cisco IOS-Konfigurationsbefehls nicht End-to-End überschreiben.

    Träger-Kapazität ist 0x8090A2 oder 0x9090A2: Sprach-/Sprachanruf (u-law)

    Träger-Kapazität ist 0x8090A3 oder 0x9090A3: Sprach-/Sprachgespräch (A-law)

    Bei dem eingehenden Anruf handelt es sich um einen analogen 64.000 Anruf. Bei Modemanwendungen wird der Anruf an die internen Modems gesendet, während bei Sprachanwendungen der Anruf an das entsprechende Sprachmodul weitergeleitet werden kann. Gehen Sie wie folgt vor:

    1. Überprüfen Sie auf der Empfängerseite, ob die physische ISDN-Schnittstelle (z. B. Schnittstelle BRI 0) ein eingehendes Sprachmodem konfiguriert hat.

    2. Stellen Sie sicher, dass die Modemleitungen mit dem Modem verbunden sind.

    Eine Beispielkonfiguration finden Sie im Dokument Configuring Modem Connectivity with a Cisco 3640 BRI.

  • Interpretieren des Trennungsursachencodes, der in der DISCONNECT- oder RELEASE-Nachricht vom angerufenen Router an den anrufenden Router gesendet wird

    Wenn der angerufene Router keine CONNECT-Nachricht an den anrufenden Router sendet, sollte er entweder eine DISCONNECT- oder eine RELEASE-Nachricht zurücksenden. Diese DISCONNECT- oder RELEASE-Nachricht sollte auch einen Trennungsursachencode enthalten. Im folgenden Beispiel lautet der Disconnect-Ursachencode 0x8090. Im Dokument Understanding isdn q931 Disconnect Cause Codes (Fehlersuche für getrennte Verbindung) finden Sie Informationen zur Interpretation des Trennungscodes.

    Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8  
    callref = 0x06
    Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing
    

Der anrufende Router erhält keine CONNECT-Meldung.

Wenn der angerufene Router eine CONNECT-Nachricht sendet, diese jedoch nicht beim anrufenden Router eingeht, liegt das Problem höchstwahrscheinlich beim Telco.

• Stellen Sie fest, ob der Router eine CONNECT_ACK vom lokalen ISDN-Switch empfängt:

  Dies zeigt an, dass der Telco-Switch in der Nähe des angerufenen Routers die CONNECT-Nachricht akzeptiert hat und die CONNECT-Nachricht an den anrufenden Router weiterleitet. Ein Ausfall des Anrufs ist wahrscheinlich ein Telekommunikationsproblem.

• Wenden Sie sich für weitere Fehlerbehebung an den Telco.

Der anrufende Router empfängt eine CONNECT-Nachricht, aber der Anruf schlägt immer noch fehl

Wenn der anrufende Router eine CONNECT-Meldung empfängt, die anzeigt, dass die ISDN-Verbindung aktiv und ordnungsgemäß funktioniert. Wenden Sie sich an den Telco, um festzustellen, ob ein Problem besteht, dass der B-Channel nicht korrekt für Daten zugeordnet wird. Jeglicher Ausfall des Anrufs in dieser Phase ist auf ein Problem mit höherer Ebene zurückzuführen, z. B. bei PPP, Authentifizierung oder IPCP/IP-Adressverhandlung. Verwenden Sie die Debug-ppp-Aushandlung für weitere ppp-Fehlerbehebung.

Weitere Informationen finden Sie im Dokument Dialup Technology: Fehlerbehebungsverfahren für weitere PPP-Fehlerbehebungsverfahren.

Zugehörige Informationen

• Seite "Technischer Support" aufrufen
• Technischer Support - Cisco Systems

Revisionsverlauf