Durchführen von Loopback-Anrufen zum Testen von BRI-Leitungen

Einführung

Dieses Dokument enthält Anweisungen zum Durchführen von Loopbacks zum Testen von BRI-Schaltungen (Basic Rate Interface).

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

• Die Ausgabe der Befehle debug isdn q931 und debug ppp negotiation.

• Allgemeine Konfigurationskonzepte für das DDR-Wählprofil. Weitere Informationen zu Dialer-Profilen finden Sie unter Konfigurieren und Beheben von Dialer-Profilen.

Bevor Sie dieses Verfahren versuchen, rufen Sie die folgenden Informationen vom Telco ab:

• Zu konfigurierender Switch-Typ

• Serviceprofilkennungen (SPID) und die lokale Verzeichnisnummer (LDN). Die SPID und die LDN sind in den Vereinigten Staaten von Amerika erforderlich.

• Legt fest, ob beide B-Kanäle in einer Sammelgruppe vorhanden sind. Wenn sie sich in einer Sammelgruppe befinden, müssen wir nur eine Nummer wählen, um einen der beiden B-Kanäle zu erreichen.

• Ob der Anruf auf der BRI-Leitung mit 56.000 oder 64.000 erfolgen muss

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Cisco IOS Software, Version 12.0(3)T und höher Der Grund hierfür ist, dass der Befehl isdn call in der Cisco IOS Software, Version 12.0(3)T, eingeführt wurde.

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.

Hintergrundinformationen

Bei einem Loopback-Anruf wählt der Router die ISDN-Nummer seiner eigenen Basic Rate Interface (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 funktioniert.

Es gibt zwei Arten von Loopback-Anrufen, die Sie zum Testen einer BRI-Leitung ausführen können:

• Ein ISDN Layer 3-Loopback-Anruf? für die Sie den Befehl isdn call interface verwenden können. Mit diesem Loopback-Anruf können Sie überprüfen, ob die ISDN-Layer 1, 2 und 3 zwischen dem Router und dem lokalen ISDN-Switch funktionieren. Dieser Test verwendet den D-Kanal und testet keine Daten über die B-Kanäle. Dies beinhaltet keine Änderungen an der Konfiguration des Routers. Führen Sie diesen Test zuerst durch. Wenn dies erfolgreich ist, führen Sie den Datenschleifenabruf-Anruftest durch.

• Ein Daten-Loopback-Anruf? die prüft, ob die B-Kanäle tatsächlich Daten übergeben können. Dies erfordert eine Konfigurationsänderung auf dem Router.

Mit diesen Verfahren können Sie nur prüfen, ob der BRI-Schaltkreis zum lokalen Switch funktioniert. Es werden keine End-to-End-ISDN-Verbindungen oder Probleme im Zusammenhang mit DDR (Dial-on-Demand Routing) getestet. Weitere Informationen zur Fehlerbehebung bei BRIs finden Sie in den folgenden Dokumenten:

• Flussdiagramm zur ISDN BRI-Fehlerbehebung

• Fehlerbehebung für ISDN BRI Layer 3 mithilfe des Befehls debug isdn q931.

Durchführen eines ISDN-Layer-3-Loopback-Anrufs

Dieser Abschnitt enthält ein Beispiel für einen erfolgreichen ISDN-Layer-3-Loopback-Anruf. Der Befehl isdn call ermöglicht ausgehende ISDN-Anrufe ohne DDR-Anforderungen wie interessanter Datenverkehr und Routen. Dieser Befehl kann nur zum Testen der ISDN-Leitung bis Layer 3 verwendet werden und kann nicht zum Übergeben von Datenverkehr oder als Ersatz für eine ordnungsgemäße DDR-Konfiguration verwendet werden. Mit diesem Befehl wird geprüft, ob der ISDN-Schaltkreis, insbesondere Layer 3, funktioniert.

Abbildung 1 zeigt den Anruffluss und einige der Meldungen debug isdn q931:

Abbildung 1: Anruffluss und einige Debug-Meldungen "isdn q931"

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

!--- The router dials 5551111 (the ISDN number of the router's own BRI). !--- If the BRI circuit has two different phone numbers for each B-channel, !--- use the number that belongs to the second B-channel. !--- You can use this command to make calls at 56k, with the speed 56 option
.
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 now processes 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 message 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 auf verschiedenen B-Kanälen. Bei der Interpretation der debug isdn q931-Ausgabe sollten Sie diese "dualen Rollen" unbedingt im Auge behalten. Beispielsweise überträgt der Router eine Setup-Meldung (TX -> SETUP) und empfängt auch eine Nachricht (RX <- SETUP). Das übertragene SETUP muss dem ausgehenden Anruf zugeordnet werden, während die empfangene SETUP-Nachricht dem eingehenden Anruf zugeordnet ist.

• Im obigen Beispiel wird die Nummer für den ersten B-Kanal gewählt. Der Telco erkennt jedoch, dass der erste B-Kanal belegt ist (da er den Anruf tätigt), und schaltet den Anruf auf den zweiten B-Kanal um, und die Verbindung wurde erfolgreich hergestellt. Eine falsche Konfiguration im telco-Switch kann jedoch zum Ausfall des Loopback-Anrufs führen. Dies kann passieren, wenn der Switch versucht, den Anruf dem ersten Kanal zuzuweisen (der gerade mit der Anrufverarbeitung beschäftigt ist). Bitten Sie den Telco, beide B-Kanäle in einer Sammelgruppe hinzuzufügen. Für diesen Test können wir jedoch die zweite B-Channel-Nummer im Befehl isdn call interface angeben, um dieses Problem zu umgehen.

• Führen Sie den Loopback-Anruf auf dem anderen Router durch.

• Wenn die Loopback-Anrufe erfolgreich sind und der Anruf am Remote-Ende weiterhin fehlschlägt, können Sie einen Daten-Loopback-Anruf versuchen, die Datenintegrität des B-Kanals zu testen, wie im nächsten Abschnitt beschrieben.

Weitere Informationen zur Fehlerbehebung finden Sie in den folgenden Dokumenten:

• Flussdiagramm zur ISDN BRI-Fehlerbehebung

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

Durchführen eines Daten-Loopback-Anrufs

Daten-Loopback-Anrufe sind nützlich, um zu testen, ob die B-Kanäle Daten ordnungsgemäß übertragen können. In vielen Situationen kann Debug-PPP-Aushandlung durchgehend fehlschlagen. Dieser Test kann verwendet werden, um die Datenintegrität auf dem B-Kanal zu überprüfen.

Hinweis: Im Unterschied zum vorherigen Test umfasst dieser Test eine Konfigurationsänderung des Routers.

In einem Datenschleifenschaltung werden zwei Dialer-Schnittstellen auf dem Router konfiguriert. Die Dialer-Schnittstelle ist mit den erforderlichen Adressierungs-, Authentifizierungs- und DDR-Befehlen konfiguriert, um sich erfolgreich auf der BRI-Leitung auszuwählen, den eingehenden Anruf entgegenzunehmen, sich an die andere Dialer-Schnittstelle zu binden und erfolgreich eine Verbindung herzustellen.

Erstellen Sie ein Wählprofil, um ein anderes Wählprofil auf demselben Router zu wählen.

Konfigurieren des Routers

Gehen Sie wie folgt vor, um den Router für den Loopback-Anruf zu konfigurieren:

1. Speichern Sie die aktuelle Konfiguration mithilfe des Befehls copy running-config startup-config. Wenn Sie dies tun, können Sie die aktuelle Konfiguration neu starten und nach Abschluss des Tests auf die Vortestversion zurücksetzen.

2. Konfigurieren Sie die physische Schnittstelle.

   Hinweis: In diesem Abschnitt wird davon ausgegangen, dass Sie die erforderlichen ISDN-bezogenen Informationen wie Switch-Typ und SPIDs kennen.

   interface BRI0
    no ip address
    
   !--- Do not configure an IP address on the physical interface. !--- The IP address will be configured on the dialer. 
   
    encapsulation ppp
    !--- physical interface uses PPP encapsulation
    dialer pool-member 1
    
   !--- Assign BRI0 as member of dialer pool 1. !--- Dialer pool 1 is specified in interface Dialer 1, and !--- interface Dialer 2.
   
    isdn switch-type basic-ni
    isdn spid1 71355511110101 5551111
    isdn spid2 71355511120101 5551112
    
   !--- switch-type and SPID configuration. !--- Contact the telco for this information. 
   
    ppp authentication chap callin   
    
   !--- The physical interface uses CHAP authentication. !--- Authentication is required on the physical interface to bind the !--- incoming call to the right dialer profile.
   
   

3. Konfigurieren Sie die erste Dialer-Schnittstelle:

   interface Dialer1
    ip address 1.1.1.1 255.255.255.0
    
   !--- Assign an IP address to the dialer interface. !--- In this example, the IP addresses for both dialers !--- are in the same subnet.
   
    encapsulation ppp
    
   !--- The dialer interface uses PPP (same as the physical BRI interface).
   
    dialer pool 1
   
    !--- his defines Dialer pool 1. BRI 0 is a member of this pool.
   
    dialer remote-name dialer2
    
   !--- This name must match the name used by the other dialer interface to !--- authenticate itself. Dialer string 7135551112. !--- Phone number for the other B-channel. !--- If your connection only needs one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
    
   !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
   
    !--- Use one-way CHAP authentication. This is sufficient for this test.
   
    ppp chap hostname dialer1
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer1
   
    !--- CHAP Password to be sent out for authentication.
   
   

4. Konfigurieren Sie die zweite Dialer-Schnittstelle:

   interface Dialer2
    ip address 1.1.1.2 255.255.255.0
   
    !--- Assign an IP address to the dialer interface. !--- In this example, IP address for both dialers are in the same subnet.
   
    encapsulation ppp
    dialer pool 1
   
    !--- This defines Dialer pool 1. !--- BRI 0 is a member of this pool.
   
    dialer remote-name dialer1
   
    !--- This name must match the name used by the other dialer interface !--- (dialer1) to authenticate itself. Dialer string 7135551111. !--- Phone number for the other B-channel. !--- If your connection only has one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
   
    !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
    ppp chap hostname dialer2
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer2
   
    !--- CHAP Password to be sent out for authentication.
   
   

5. Konfigurieren Sie den Benutzernamen und die Kennwörter für die Authentifizierung:

   username dialer1 password 0 dialer1
   username dialer2 password 0 dialer2
   

   Der Benutzername und die Kennwörter entsprechen denen, die Sie mithilfe der Befehle ppp chap hostname und ppp chap password konfiguriert haben.

6. Konfigurieren Sie statische Routen für Klarheit:

   ip route 1.1.1.1 255.255.255.255 Dialer1
   
   !--- Note that the route for 1.1.1.1 points to dialer1.
   
   ip route 1.1.1.2 255.255.255.255 Dialer2
   
   !--- Note that the route for 1.1.1.2 points to dialer2. !--- The routes are used to determine which dialer interface is !--- used for dialout.
   
   

   Tipp: Wenn Sie die IP-Adressen für die Schnittstelle Dialer 1 (Schritt 3) und die Schnittstelle Dialer 2 (Schritt 4) in separaten Subnetzen konfigurieren, sind die statischen Routen nicht erforderlich.

7. Konfigurieren Sie die interessante Datenverkehrsdefinition.

   dialer-list 1 protocol ip permit

   Hinweis: Die Nummer der Dialer-Liste muss mit der Nummer übereinstimmen, die in der Dialer-Gruppe unter der Dialer-Schnittstelle konfiguriert wurde. In diesem Beispiel konfigurieren Sie Dialer-Liste 1.

8. Wenn der Test abgeschlossen ist, laden Sie den Router neu (speichern Sie die Konfiguration nicht), um zur ursprünglichen Konfiguration zurückzukehren, die vor dem Test verwendet wurde.

Initiieren des Daten-Loopback-Anrufs

Wir starten nun den Daten-Loopback-Anruf und suchen nach dem erfolgreichen Abschluss der PPP-Aushandlung. Eine erfolgreiche PPP-Aushandlung weist darauf hin, dass die B-Kanäle Daten ordnungsgemäß übergeben können.

Abbildung 2: Initiieren des Daten-Loopback-Anrufs

Aktivieren Sie diese Debugger:

• Debug Dialer

• debug isdn q931

• Debug-ppp-Aushandlung

• debug ppp authentication (optional)

Hinweis: Wenn der Loopback-Anruf ausgeführt wird, fungiert der Router sowohl als angerufener Router als auch als anrufender Router auf verschiedenen B-Kanälen. Bei der Interpretation der Ausgabe der Befehle debug isdn q931 und debug ppp negotiation ist es wichtig, dass Sie diese "dualen Rollen" im Auge behalten. Beispielsweise überträgt der Router eine Setup-Meldung (TX -> SETUP) und empfängt auch eine Nachricht (RX <- SETUP). Das übertragene SETUP muss dem ausgehenden Anruf zugeordnet werden, während die empfangene SETUP-Nachricht dem eingehenden Anruf zugeordnet ist.

Hier sind die Debugging für den Back-to-Back-ISDN-Anruf:

router#show debug
Dial on demand:
  Dial on demand events debugging is on
PPP:
  PPP protocol negotiation debugging is on
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 1
  1 -

router#ping 1.1.1.1

!--- Because of the static route entry shown in step 6 above, !--- the call is made out from dialer 1. 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

03:40:41: BR0 DDR: rotor dialout [priority]
03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1)
03:40:41: BR0 DDR: Attempting to dial 7135551112
03:40:41: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x08

!--- Outgoing SETUP message.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x83
03:40:41:         Keypad Facility i = '7135551112'
03:40:41: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x88
03:40:41:         Channel ID i = 0x89
03:40:41: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x2A

!--- Incoming SETUP message on the other B-channel.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x8A
03:40:41:         Signal i = 0x40 - Alerting on - pattern 0
03:40:41:         Called Party Number i = 0xC1, '5551112', Plan:ISDN,
  Type:Subscriber(local)
03:40:41:         Locking Shift to Codeset 5
03:40:41:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
03:40:42: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s

!--- Note that the call comes in on the second B-channel (BRI0:2). !--- Hence the outgoing call must have been on BRI0:1.

03:40:42: ISDN BR0: Event: Accepting the call id 0xB
03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up.
03:40:42: BR0:2 PPP: Treating connection as a callin
03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load]
03:40:42: BR0:2 LCP: State is Listen

!--- PPP LCP negotiations begin. 

03:40:42: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x2A
03:40:42:         Channel ID i = 0x8A
03:40:42:         Signal i = 0x4F - Alerting off
03:40:42: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x88
03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:40:42: BR0:1: interface must be fifo queue, force fifo
03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
03:40:42: BR0:1 PPP: Treating connection as a callout
03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:40:42: BR0:1 PPP: No remote authentication for call-out

!--- One-way authentication (configured with PPP authentication CHAP callin).

03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x08
03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15
03:40:42: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: State is Open
03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15
03:40:43: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:43: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:43: BR0:2 LCP: State is Open
03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]

!--- Authentication begins.

03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: Using alternate hostname dialer1

!--- Use the alternate hostname specified with PPP CHAP hostname !--- under int Dialer 1.

03:40:43: BR0:1 CHAP: Username router not found
03:40:43: BR0:1 CHAP: Using default password
03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1"

!--- Outgoing CHAP response sent on B-channel 1. 

03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1"

!--- Incoming CHAP response seen on B-channel 2.

03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4

!--- Authentication is successful

03:40:43: BR0:2: interface must be fifo queue, force FIFO
03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2

!--- Call (from Dialer 1) is bound to int Dialer 2. !--- This is because the dialer remote-name dialer1 command is !--- configured under int dialer 2. Binding fails when the dialer remote-name !--- command is omitted, or is incorrect, .

03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load]

!--- IPCP negotiation begins.

03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4
03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load]
03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 IPCP: State is Open

!--- IPCP on B-channel 2 is Open.

03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 IPCP: State is Open

!--- IPCP on B-channel 1 is Open.

03:40:43: BR0:2 DDR: dialer protocol up
03:40:43: BR0:1 DDR: dialer protocol up
03:40:43: Di2 IPCP: Install route to 1.1.1.1
03:40:43: Di1 IPCP: Install route to 1.1.1.2
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, 
changed state to up
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, 
changed state to up

!--- Both B-channels are up.

...
Success rate is 0 percent (0/5)
router#

Hinweis: Die Pings können aufgrund von Routing-Problemen fehlschlagen. Sie können das erwarten. Die erfolgreiche PPP-Aushandlung ist der wahre Test dafür, ob die B-Kanäle die Daten der Verbindung ordnungsgemäß weitergeben können. Wenn der Anruf fehlschlägt, wenden Sie sich an den Telekommunikationsanbieter, um weitere Informationen zur Fehlerbehebung für die Leitung zu erhalten.

Zugehörige Informationen

• Flussdiagramm zur ISDN BRI-Fehlerbehebung
• Fehlerbehebung für ISDN BRI Layer 3 mit dem Befehl debug isdn q931
• Konfigurieren und Beheben von Dialer-Profilen
• PPP-Authentifizierung mit dem PPP-chap-Hostnamen und den ppp-Authentifizierungschap-Callin-Befehlen
• Unterstützung von DFÜ- und Zugriffstechnologie
• Technischer Support und Dokumentation - Cisco Systems

Revisionsverlauf