Esecuzione di chiamate di loopback per il test dei circuiti BRI

Introduzione

In questo documento viene spiegato come eseguire i loopback per verificare i circuiti BRI (Basic Rate Interface).

Prerequisiti

Requisiti

Questo documento è utile per conoscere i seguenti argomenti:

• L'output dei comandi debug isdn q931 e debug ppp negotiation.

• Concetti generali relativi alla configurazione del profilo dialer DDR. Per ulteriori informazioni sui profili dialer, vedere Configurazione e risoluzione dei problemi dei profili dialer.

Prima di provare a eseguire questa procedura, richiedere le seguenti informazioni alla Telco:

• Tipo di switch da configurare.

• identificatori del profilo del servizio (SPID) e numero di directory locale (LDN). SPID e LDN sono obbligatori negli Stati Uniti.

• Se entrambi i canali B si trovano in un gruppo di risposta. Se si trovano in un gruppo di ricerca, è sufficiente comporre un solo numero per raggiungere il canale B.

• Se la chiamata sulla linea BRI deve essere effettuata a 56k o 64k

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Software Cisco IOS versione 12.0(3)T e successive. Infatti il comando isdn call è stato introdotto nel software Cisco IOS versione 12.0(3)T.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

In una chiamata di loopback, il router compone il numero ISDN della propria interfaccia BRI (Basic Rate Interface). La chiamata procede al cloud di telco, dove il telefono passa al secondo canale BRI. Questa chiamata viene ora vista dal router come una chiamata in arrivo sul secondo canale. Pertanto, il router invia e riceve la chiamata ISDN.

Una chiamata loopback verifica la capacità del router di avviare e terminare una chiamata ISDN. Una chiamata di loopback riuscita fornisce una forte indicazione che il circuito ISDN al telco cloud è funzionante.

Per verificare un circuito BRI è possibile eseguire due tipi di chiamate di loopback:

• Una chiamata di loopback al layer 3 ISDN ??? per la quale è possibile utilizzare il comando isdn call interface. Questa chiamata di loopback consente di verificare se i livelli ISDN 1, 2 e 3 sono funzionanti tra il router e lo switch ISDN locale. Questo test utilizza il canale D e non verifica i dati sui canali B. Non comporta modifiche alla configurazione del router. Eseguire prima questo test. Se l'operazione ha esito positivo, provare a eseguire il test della chiamata di loopback dei dati.

• Chiamata di loopback dei dati ??? che verifica se i canali B possono effettivamente passare dati. Ciò comporta una modifica della configurazione del router.

Queste procedure consentono solo di verificare il funzionamento del circuito BRI allo switch locale. Non testa la connettività ISDN end-to-end né i problemi relativi al routing DDR (dial-on-demand routing). Per ulteriori informazioni sulla risoluzione dei problemi relativi agli BRI, consultare i seguenti documenti:

• Diagramma di flusso per la risoluzione dei problemi di ISDN BRI

• Risoluzione dei problemi di ISDN BRI layer 3 con il comando debug isdn q931

Esecuzione di una chiamata di loopback ISDN layer 3

In questa sezione viene illustrato un esempio di chiamata di loopback ISDN layer 3 riuscita. Il comando isdn call abilita le chiamate ISDN in uscita senza requisiti DDR, ad esempio il traffico e le route interessanti. Questo comando può essere usato solo per verificare il circuito ISDN fino al layer 3 e non può essere usato per far passare il traffico o per sostituire la corretta configurazione DDR. Questo comando verifica se il circuito ISDN, in particolare il layer 3, è funzionante.

La Figura 1 mostra il flusso di chiamate e alcuni messaggi debug isdn q931:

Figura 1 - Flusso di chiamata e alcuni messaggi debug 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.

Note:

• Durante la chiamata di loopback, il router svolge le funzioni di router chiamato e di router chiamante su diversi canali B. È importante tenere traccia di questi "ruoli doppi" quando si interpreta l'output debug isdn q931. Ad esempio, il router trasmette un messaggio di installazione (TX -> SETUP) e ne riceve uno (RX <- SETUP). L'impostazione trasmessa deve essere associata alla chiamata in uscita mentre il messaggio SETUP ricevuto è associato alla chiamata in ingresso.

• Nell'esempio precedente viene composto il numero del primo canale B. Tuttavia, il telecom riconosce che il primo canale B è occupato (poiché effettua la chiamata) e passa la chiamata al secondo canale B e la connessione è stata completata correttamente. Tuttavia, una configurazione errata nello switch telco può ostacolare il corretto completamento della chiamata di loopback. Questa situazione può verificarsi quando lo switch cerca di assegnare la chiamata al primo canale (occupato a effettuare la chiamata). Chiedere al telco di aggiungere entrambi i canali B in un gruppo di ricerca. Tuttavia, per risolvere questo problema, è possibile specificare il secondo numero del canale B nel comando isdn call interface.

• Eseguire la chiamata di loopback sull'altro router.

• Se le chiamate di loopback hanno esito positivo e la chiamata all'estremità remota continua a non riuscire, è possibile provare una chiamata di loopback dei dati per verificare l'integrità dei dati del canale B come descritto nella sezione successiva.

Per informazioni su come risolvere i problemi, consultare i seguenti documenti:

• Diagramma di flusso per la risoluzione dei problemi di ISDN BRI

• Risoluzione dei problemi di ISDN BRI layer 3 con il comando debug isdn q931

Esecuzione di una chiamata di loopback dei dati

Le chiamate di loopback dei dati sono utili per verificare se i canali B possono trasmettere correttamente i dati. In molte situazioni, la negoziazione ppp di debug può non riuscire continuamente. Questo test può essere utilizzato per verificare l'integrità dei dati sul canale B.

Nota: a differenza del test precedente, questo test implica una modifica della configurazione del router.

In una chiamata di loopback dei dati, vengono configurate due interfacce dialer sul router. L'interfaccia della connessione remota è configurata con i comandi di indirizzamento, autenticazione e DDR necessari per la connessione alla linea BRI, la ricezione della chiamata in ingresso, il binding all'altra interfaccia della connessione e la corretta connessione.

Creare un profilo dialer per comporre un altro profilo dialer sullo stesso router.

Configurazione del router

Per configurare il router per la chiamata di loopback, attenersi alla seguente procedura:

1. Salvare la configurazione in esecuzione con l'aiuto del comando copy running-config startup-config. In questo caso, è possibile riavviare e ripristinare la configurazione corrente nella versione precedente al test al termine del test.

2. Configurare l'interfaccia fisica.

   Nota: in questa sezione si presume che l'utente sia a conoscenza delle informazioni ISDN necessarie, ad esempio il tipo di switch e gli SPID.

   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. Configurare la prima interfaccia di connessione:

   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. Configurare la seconda interfaccia di connessione:

   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. Configurare il nome utente e le password per l'autenticazione:

   username dialer1 password 0 dialer1
   username dialer2 password 0 dialer2
   

   Il nome utente e la password sono gli stessi configurati con l'aiuto dei comandi ppp chap hostname e ppp chap password in ciascuna interfaccia di connessione.

6. Configurare le route statiche per la chiarezza:

   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.
   
   

   Suggerimento: se si configurano gli indirizzi IP per l'interfaccia Dialer 1 (passaggio 3) e l'interfaccia Dialer 2 (passaggio 4) in subnet separate, le route statiche non sono necessarie.

7. Configurare la definizione del traffico interessante.

   dialer-list 1 protocol ip permit

   Nota: il numero dell'elenco di composizione deve coincidere con quello configurato in dialer-group nell'interfaccia di composizione. Nell'esempio, configurare dialer-list 1.

8. Al termine del test, ricaricare il router (non salvare la configurazione) per tornare alla configurazione originale utilizzata prima del test.

Avvia la chiamata di loopback dei dati

Verrà ora avviata la chiamata di loopback dei dati e verrà verificato il completamento della negoziazione PPP. Una negoziazione PPP riuscita indica che i canali B possono passare i dati in modo corretto.

Figura 2 - Avvio della chiamata di loopback dei dati

Attiva questi debug:

• debug dialer

• debug isdn q931

• negoziazione ppp di debug

• debug ppp authentication (facoltativo)

Nota: quando la chiamata di loopback è in corso, il router svolge le funzioni di router chiamato e di router chiamante su diversi B-channel. È importante tenere traccia di questi "ruoli doppi" quando si interpreta l'output dei comandi di negoziazione debug isdn q931 e debug ppp. Ad esempio, il router trasmette un messaggio di installazione (TX -> SETUP) e ne riceve uno (RX <- SETUP). L'impostazione trasmessa deve essere associata alla chiamata in uscita, mentre il messaggio SETUP ricevuto è associato alla chiamata in arrivo.

Di seguito sono riportati i debug della chiamata ISDN back-to-back:

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#

Nota: i ping possono non riuscire a causa di problemi relativi al routing. Potete aspettarvi questo. La riuscita della negoziazione PPP è la vera verifica della capacità dei canali B di passare correttamente i dati sul collegamento. Se la chiamata non riesce, contattare il telefono per ulteriori informazioni su come risolvere il problema della linea.

Informazioni correlate

• Diagramma di flusso per la risoluzione dei problemi di ISDN BRI
• Risoluzione dei problemi di ISDN BRI layer 3 con il comando debug isdn q931
• Configurazione e risoluzione dei problemi dei profili dialer
• Autenticazione PPP utilizzando i comandi ppp chap hostname e ppp authentication chap callin
• Supporto della tecnologia Dial and Access
• Documentazione e supporto tecnico – Cisco Systems

Cronologia delle revisioni