Diagramma di flusso per la risoluzione dei problemi di ISDN BRI
Sommario
Introduzione
Questo documento aiuta a risolvere i problemi relativi all'accesso remoto BRI (ISDN Basic Rate Interface). Nel diagramma di flusso e nell'output di esempio mostrato di seguito è stata impostata una connessione ISDN BRI a un altro utente mediante i profili dialer. Tuttavia, le stesse procedure di risoluzione dei problemi si applicano alle connessioni con altri router (ad esempio filiali) e quando si utilizza il routing DDR (Dial-on-Demand Routing) legacy.
Nota: È possibile usare anche la Cisco Support Community per risolvere il problema ISDN.
Per informazioni introduttive su ISDN e DDR, fare riferimento alla formazione sull'audio disponibile in Cisco Learning Connection.
Diagramma di flusso
Fai clic su uno dei link qui sotto per ottenere ulteriori informazioni sull'oggetto. Utilizzare il pulsante Indietro del browser per tornare al diagramma di flusso.
Risoluzione dei problemi: Come accedere e acquisire i debug
È possibile collegarsi al router tramite il cavo console collegato alla porta seriale del PC o tramite telnet.
Se è necessario connettersi al router tramite la console, vedere Applicazione delle impostazioni corrette dell'emulatore di terminale per le connessioni della console. Se il router è già configurato per la connettività su Ethernet e si desidera collegarsi al router tramite telnet, è sufficiente utilizzare un client telnet per collegarsi all'indirizzo IP Ethernet del router.
In ogni caso (console o telnet), è preferibile utilizzare un client che consenta di conservare una cronologia dell'output ricevuto durante la sessione, in quanto potrebbe essere necessario scorrere l'output di debug per cercare determinati messaggi.
Attivare in millisecondi l'output di debug e i messaggi di registro. Quando richiesto, immettere la password configurata sul router e accedere alla modalità di abilitazione:
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
Se si è connessi tramite telnet, digitare terminal monitor come segue:
router#terminal monitor router#
Di seguito, immettere i comandi di debug:
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#
Quindi, avviare il ping sul router chiamante. Di seguito è riportato un esempio di output del comando debug per una chiamata completata. Vengono evidenziate le diverse fasi identificate nel diagramma di flusso.
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#
Torna al diagramma di flusso per la risoluzione dei problemi
Risoluzione dei problemi: Il router tenta di comporre il numero?
Per verificare se il router tenta di effettuare una chiamata, verificare di avere le seguenti righe nell'output di debug del router chiamante:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
Nell'output del debug, 8134 è il numero della directory ISDN che il router sta tentando di comporre. Questo numero è stato specificato con il comando dialer string o dialer map.
Torna al diagramma di flusso per la risoluzione dei problemi
Sintomo: Il router non tenta di comporre il numero
Se il router non sta tentando di comporre il numero, esistono diverse possibilità:
Nessun output di debug
Se non è presente alcun output di debug, è probabile che il pacchetto IP che si sta inviando non sia nemmeno indirizzato all'interfaccia Dialer. Le cause più comuni sono:
- Verificare che IP sia configurato sull'interfaccia Dialer. È necessario disporre di un indirizzo ip sull'interfaccia del dialer o di un'interfaccia ip senza numero (dove interface è un'interfaccia up/up come ethernet x, loopback x ecc.) o un indirizzo ip negoziato (se il client ottiene un indirizzo IP dal NAS). Se si utilizza un DDR legacy, l'indirizzo IP deve essere configurato sull'interfaccia fisica (ad esempio, interfaccia BRI 0).
- Verificare che il comando ip routing sia configurato. Se si controlla la configurazione utilizzando il comando show running-config, il comando no ip routing non dovrebbe essere visualizzato.
- Verificare che sia presente un percorso statico che punta all'interfaccia della connessione telefonica o all'hop successivo (se si utilizzano mappe dialer).
L'esempio seguente (per il profilo dialer) è una route statica per 172.22.53.0/24 con Next Hop Dialer 1:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
L'esempio seguente (per il DDR legacy) è un percorso statico per 172.22.53.0/24 con hop successivo 172.16.1.1. L'indirizzo dell'hop successivo deve corrispondere all'indirizzo ip nell'istruzione della mappa del dialer utilizzata per la composizione:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- Verificare che l'interfaccia fisica o di connessione telefonica non si trovi nello stato disattivato o in standby a livello amministrativo. Per verificare che l'interfaccia sia nello stato attivo/attivo (spoofing), usare il comando show interface dialer X o show interface bri X.
Se l'interfaccia è disattivata a livello amministrativo, usare il comando no shutdown in modalità di configurazione interfaccia.
Se l'interfaccia è in stato standby, l'interfaccia dialer o BRI è un backup di una connessione attiva. È possibile rimuovere il comando backup interface dall'interfaccia primaria oppure estrarre il cavo dall'interfaccia primaria.
È presente l'output di debug ma non il messaggio "Tentativo di composizione in corso"
In questo caso, probabilmente è presente un pacchetto IP indirizzato all'interfaccia, ma il router lo scarta e per qualche motivo non avvia la chiamata. Esaminare l'output del comando debug per individuare la causa del mancato tentativo di chiamata. Di seguito vengono riportati alcuni output di debug di esempio e le possibili cause:
Esempio 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).
Il traffico generato non corrisponde alla definizione del traffico interessante. Per questo esempio, modificare access-list 101.
Una definizione semplice e interessante del traffico potrebbe essere quella di consentire tutto il traffico IP, come in:
maui-soho-01(config)#dialer-list 1 protocol ip permit
Avviso: Se si contrassegna tutto il traffico IP come interessante, il collegamento ISDN potrebbe rimanere attivo per un periodo di tempo indefinito, in particolare se si dispone di un protocollo di routing o di altro traffico periodico. Adatta la definizione del traffico interessante alle tue esigenze.
Per ulteriori informazioni sul traffico interessante, consultare il documento Tecnologia di accesso remoto: Panoramiche e spiegazioni.
Esempio 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).
Nessun gruppo di composizione configurato sull'interfaccia di composizione. Aggiungere un gruppo dialer come nell'esempio seguente:
interface Dialer1 dialer-group X
Nota: Il valore di X deve essere lo stesso utilizzato con il comando dialer-list.
Esempio 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).
Sull'interfaccia della connessione è presente un'istruzione dialer-group, ma l'elenco delle connessioni telefoniche a cui si fa riferimento non esiste. Configurare l'elenco di composizione come nell'esempio seguente:
dialer-list X protocol ip permit
Nota: Il valore di X deve essere lo stesso utilizzato con il comando dialer-group nell'interfaccia dialer.
Esempio 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 questo caso, il pacchetto in uscita deve essere considerato abbastanza interessante da richiamare il collegamento, ma non è disponibile un'interfaccia fisica per effettuare la chiamata. Verificare che il membro X del pool di dialer sia configurato nell'interfaccia fisica e che il pool di dialer X sia configurato nell'interfaccia Dialer. Esempio:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
Verificare inoltre che l'interfaccia BRI non sia nello stato shutdown.
Esempio 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 questo caso, sull'interfaccia non è configurata alcuna stringa di connessione. Il router desidera effettuare una chiamata ma non conosce il numero di directory ISDN da chiamare. Definire una stringa da comporre:
interface Dialer1 dialer string 8134
Per ulteriori informazioni sulla risoluzione dei problemi, consultare la sezione "The Calling Router does not send a SETUP Message" nel documento sulla risoluzione dei problemi relativi a ISDN BRI layer 3 con il comando debug isdn q931.
Torna al diagramma di flusso per la risoluzione dei problemi
Risoluzione dei problemi: La connessione delle chiamate ISDN è riuscita?
Per verificare se la chiamata ISDN si connette, cercare un messaggio CONNECT_ACK e %LINK-3-UPDOWN nei messaggi di debug:
*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
Se viene visualizzato questo messaggio, la chiamata ISDN è stata connessa correttamente ed è possibile procedere al passaggio successivo. Se non viene visualizzato un messaggio di questo tipo, vedere di seguito le possibili cause.
Torna al diagramma di flusso per la risoluzione dei problemi
Sintomo: Connessione della chiamata ISDN non riuscita
- Se viene visualizzato un output simile al seguente, verificare che il cavo ISDN sia collegato sia al router sia alla presa Telco.
*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)
- Verificare che il circuito ISDN funzioni correttamente. Utilizzare il comando show isdn status per verificare che il layer 1 sia ACTIVE, il layer 2 sia MULTIPLE_FRAME_DEFINED e gli SPID (se necessario) siano validi. Per ulteriori informazioni, consultare il documento relativo all'utilizzo del comando show isdn status per la risoluzione dei problemi BRI.
se il dispositivo Cisco restituisce i risultati di un comando show isdn status, è possibile usare Cisco CLI Analyzer per visualizzare i potenziali errori e correggerli. Per utilizzare Cisco CLI Analyzer, è necessario essere un utente registrato, aver eseguito l'accesso e avere JavaScript abilitato. - Verificare che la stringa di connessione ISDN configurata sia corretta. Tenere presente che potrebbe essere necessario aggiungere uno zero iniziale, nove o altre cifre per ottenere una linea esterna quando si è connessi tramite un PBX.
- Se la connessione utilizza un operatore di telefonia fissa, contattare il provider di servizi di telefonia fissa locale per verificare che il servizio sia attivato. Spesso, la Telco locale ha un circuito ISDN non configurato correttamente in modo che le chiamate ISDN in uscita su lunghe distanze non vengano commutate sulla rete del provider di servizi a lunga distanza appropriato. È inoltre consigliabile verificare che la rete di provider di servizi a lunga distanza sia funzionante.
Negli Stati Uniti, e in situazioni in cui il fornitore di telecomunicazioni o di telefonia fissa non è in grado di risolvere il problema, è possibile utilizzare un vettore interscambio pre-sottoscritto (PIC). I codici PIC sono prefissi a sette cifre che identificano i vettori statunitensi di lunga distanza con i vettori locali (LEC). Questo consente ai clienti di utilizzare diversi vettori per chiamate interurbane. Il codice PIC è configurato come prefisso del numero composto. La maggior parte dei file PIC sono nel formato 1010xxx.
Utilizzare no dialer string xxxxx o no dialer map per rimuovere il numero esistente e quindi configurare il nuovo numero.
Ad esempio, la stringa dialer 10103215125551111.
- Cercare un messaggio ISDN disconnect.
Il software Cisco IOS® decodifica il codice causa in questo messaggio di disconnessione e fornisce un messaggio di testo chiaro che spesso contiene informazioni utili che conducono alla causa del problema. Le stringhe che è possibile trovare includono:
- Numero non allocato o non assegnato
- Destinazione incompatibile (entrambe indicano che il numero composto potrebbe essere errato)
- Numero occupato (indica che il lato chiamato è occupato)
- Errore temporaneo (che indica un'interruzione temporanea della rete Telco)
Per individuare la possibile causa di una disconnessione specifica, consultare il documento sulla descrizione dei codici della causa di disconnessione del debug isdn q931.
Ad esempio, una disconnessione dovuta a un numero ISDN errato può essere indicata con:
*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
Facendo riferimento al documento Disconnect Cause Codes menzionato in precedenza, è possibile stabilire che il codice di disconnessione è stato causato da un tentativo di connessione a un'apparecchiatura non ISDN (ad esempio, una linea analogica).
Una disconnessione dovuta a un numero formattato in modo errato può essere indicata con:
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)Per ulteriori informazioni sul debug isdn q931 Disconnect Cause Codes, fare riferimento al documento Comprensione del debug isdn q931 Disconnect Cause Codes. Il codice di disconnessione è stato causato da un formato non valido per il numero ISDN remoto. La connessione non riesce perché l'indirizzo di destinazione è presentato (allo switch) in un formato non riconoscibile oppure l'indirizzo di destinazione è incompleto.
Nell'esempio seguente viene illustrata una chiamata rifiutata a causa di un numero ISDN non corretto:
*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
- Se in Telco sono stati forniti gli identificatori del profilo del servizio (SPID) da utilizzare, verificare che tali SPID siano configurati nell'interfaccia BRI. Gli SPID sono comunemente usati solo negli Stati Uniti e con switch di tipo NI e DMS (gli switch di tipo 5ess non necessitano di SPID).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
Per verificare la correttezza degli SPID, usare il comando show isdn status.
Per ulteriori informazioni, consultare il documento sulla risoluzione dei problemi relativi agli SPID ISDN BRI.
se il dispositivo Cisco restituisce i risultati di un comando show isdn status, è possibile usare Cisco CLI Analyzer per visualizzare i potenziali errori e correggerli. Per utilizzare Cisco CLI Analyzer, è necessario essere un utente registrato, aver eseguito l'accesso e avere JavaScript abilitato. - Se la procedura descritta sopra non ha risolto il problema, utilizzare il documento Risoluzione dei problemi di ISDN BRI Layer 3 con il comando debug isdn q931 per ulteriori informazioni sulla risoluzione del problema.
Torna al diagramma di flusso per la risoluzione dei problemi
Risoluzione dei problemi: La fase PPP LCP ha esito positivo?
Nell'output del comando debug dovrebbe essere visualizzato un messaggio per indicare quanto segue:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
Se viene visualizzata questa riga, significa che il protocollo LCP (Link Control Protocol) è stato negoziato correttamente. Qualsiasi stato diverso da aperto indica che LCP non è riuscito.
Torna al diagramma di flusso per la risoluzione dei problemi
Sintomo: Fase LCP PPP non riuscita
Possibile causa: PPP non configurato
Se l'output del comando debug è simile alle righe seguenti, il protocollo PPP non è stato avviato.
*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)
Dall'output del debug, il router non invia messaggi PPP CONFREQ. Probabilmente l'interfaccia non è stata configurata per l'incapsulamento PPP.
In questo caso, verificare di aver configurato il comando encapsulation ppp nell'interfaccia del dialer e nell'interfaccia fisica. Ecco alcuni esempi:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
Possibile causa: Mancata corrispondenza della velocità ISDN
A volte è possibile visualizzare solo i messaggi LCP CONFREQ in uscita, ma non i messaggi LCP in entrata. Di seguito è riportato un esempio:
*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)
Il problema potrebbe essere causato da:
- L'estremità remota non è configurata per PPP. Configurare il comando encapsulation ppp sull'estremità remota
- Pacchetti che non passano attraverso i supporti di trasmissione. La causa più comune è una mancata corrispondenza della velocità ISDN
Dal punto di vista ISDN, il problema è che un lato sta probabilmente connettendo a 56k, mentre l'altro sta connettendo a 64k. È possibile che il circuito locale o remoto non supporti le connessioni predefinite a 64K. Provare a configurare entrambe le estremità in modo che funzionino a 56k.
Per i profili dialer:
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)
Per DDR legacy (mappe dialer):
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
Possibile causa: I due router non concordano sull'uso del protocollo di autenticazione (CHAP o PAP)
Se l'output del comando debug è simile alle righe seguenti, il router e il dispositivo remoto non sono concordi su un protocollo di autenticazione da utilizzare:
*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
In questo caso, verificare di aver configurato quanto segue:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
Per ulteriori informazioni su CHAP (Challenge Handshake Authentication Protocol) o PAP (Password Authentication Protocol), fare riferimento ai seguenti documenti:
- Descrizione e configurazione dell'autenticazione CHAP nei server PPP
- Autenticazione PPP utilizzando i comandi ppp chap hostname e ppp authentication chap callin
- Configurazione e risoluzione dei problemi del protocollo PAP (PPP Password Authentication Protocol)
È inoltre possibile utilizzare la Cisco Support Community per ulteriori operazioni di risoluzione dei problemi relativi al protocollo PPP.
Torna al diagramma di flusso per la risoluzione dei problemi
Risoluzione dei problemi: L'autenticazione PPP ha esito positivo?
Controllare l'output del comando debug per una riga simile a questa:
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
Torna al diagramma di flusso per la risoluzione dei problemi
Sintomo: Autenticazione PPP non riuscita
Accertarsi di aver configurato le seguenti righe:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
Nell'esempio, XXXXX è il nome utente e YYYY è la password.
Nota: Configurare solo il nome utente e la password per il metodo di autenticazione utilizzato dall'utente e dal peer. Ad esempio, se entrambi non utilizzeranno il protocollo PAP, il comando ppp pap send-username non sarà necessario. Tuttavia, se non si è certi che il peer supporti PAP o CHAP, configurare entrambi.
A seconda della versione e della configurazione del software Cisco IOS, la password potrebbe essere crittografata nella configurazione. In questo caso, quando si esegue un comando show running-configuration, viene visualizzata la parola "password" seguita dalla cifra 7 e quindi da una sequenza di numeri, come nell'esempio seguente:
interface Dialer1 ppp chap password 7 140005
In questo caso, esaminando la configurazione, non è possibile verificare se la password configurata è corretta o meno. Per verificare che la password sia corretta, accedere semplicemente alla modalità di configurazione e rimuovere e configurare nuovamente la password. Per identificare un errore di password nel debug, confrontare l'output del comando debug con l'output di esempio riportato di seguito.
Se il router esegue l'autenticazione del peer, configurare il comando username username password password, dove username è il nome fornito dal router peer per l'autenticazione.
Esempio 1
Un messaggio simile a quello seguente indica che la password CHAP non è valida.
*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
Suggerimento: Errore CHAP in ingresso (indicato da CHAP: I FAILURE) indica che il peer non è stato in grado di autenticare il router. Usare la negoziazione PPP di debug sul router peer per determinare la causa esatta dell'errore.
Per ulteriori informazioni, consultare il documento Autenticazione PPP usando i comandi ppp chap hostname e ppp authentication chap callin.
Esempio 2
Un messaggio simile a quello seguente potrebbe indicare che il nome utente CHAP non è valido:
*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
Suggerimento: Errore CHAP in ingresso (indicato da CHAP: I FAILURE) indica che il peer non è stato in grado di autenticare il router. Usare la negoziazione PPP di debug sul router peer per determinare la causa esatta dell'errore.
Per ulteriori informazioni, consultare il documento Autenticazione PPP usando i comandi ppp chap hostname e ppp authentication chap callin.
Esempio 3
Un messaggio come quello riportato di seguito indica che la password PAP non è valida:
*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
Per ulteriori informazioni, consultare il documento sulla configurazione e la risoluzione dei problemi relativi al protocollo PAP (PPP Password Authentication Protocol).
Esempio 4
Un messaggio come quello riportato di seguito indica che il nome utente PAP non è valido:
*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
Per ulteriori informazioni, consultare il documento sulla configurazione e la risoluzione dei problemi relativi al protocollo PAP (PPP Password Authentication Protocol).
È inoltre possibile utilizzare la Cisco Support Community per un'ulteriore risoluzione dei problemi relativi al protocollo PPP.
Torna al diagramma di flusso per la risoluzione dei problemi
Risoluzione dei problemi: La fase PPP NCP (IPCP) è completata?
L'elemento chiave negoziato in IPCP è l'indirizzo di ciascun peer. Prima della negoziazione IPCP, ciascun peer si trova in uno dei due stati possibili; o ha un indirizzo IP o no. Se il peer dispone già di un indirizzo, lo invia in una richiesta CONFREQ all'altro peer. Se l'indirizzo è accettabile per l'altro peer, viene restituito CONFACK. Se l'indirizzo non è accettabile, la risposta è un CONFNAK contenente un indirizzo che il peer deve utilizzare.
Questa è l'unica fase che non può essere identificata correttamente osservando solo una linea. Per verificare che il protocollo IPCP (IP Control Protocol) venga visualizzato correttamente, è necessario verificare che gli indirizzi IP siano stati negoziati in entrambe le direzioni. Controllare le righe seguenti del comando debug:
*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)
e
*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)
e
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
Queste tre serie di linee non possono seguirsi immediatamente. È importante verificare se è presente un messaggio di conferma della configurazione in uscita (O CONFACK) contenente, tra le altre opzioni, un indirizzo sottostante.
Deve inoltre essere presente un messaggio di conferma della configurazione in ingresso (I CONFACK) con un altro indirizzo IP sottostante.
Infine, deve essere presente una riga che indica che lo stato IPCP è aperto. Quindi, dovrebbe essere possibile eseguire correttamente il ping di entrambi gli indirizzi IP direttamente dal router.
Torna al diagramma di flusso per la risoluzione dei problemi
Sintomo: Negoziazione PPP NCP (IPCP) non riuscita
Problema: Negoziazione indirizzo IP non riuscita
Uno dei motivi per cui l'IPCP potrebbe non riuscire è un errore di negoziazione dell'indirizzo IP. Ad esempio, il NAS potrebbe tentare di assegnare un indirizzo al client mentre il router del client ha un indirizzo IP configurato diverso o un altro problema comune è quando il client richiede un indirizzo e il NAS non ha alcun indirizzo disponibile per il client.
Sul router chiamante:
Se il router chiamato assegna dinamicamente un indirizzo IP al router chiamante, verificare di avere il comando ip address negoziato nell'interfaccia del dialer.
Se il provider NAS/ISP ha fornito un indirizzo IP statico, verificare che questo indirizzo ip (e la subnet mask) sia configurato nell'interfaccia di connessione con il comando ip address subnet_mask.
Sul router chiamato:
Verificare che l'interfaccia che controlla la connessione (ad esempio, int Dialer x) disponga di un indirizzo IP e stia assegnando un indirizzo al peer utilizzando il comando peer default ip address address.
Nota: Se sul router client è configurato un indirizzo IP, non è necessario assegnare un indirizzo utilizzando il comando peer default ip address
Per ulteriori informazioni, consultare il documento Tecnologia di connessione remota: Tecniche di risoluzione dei problemi.
Problema: Il router chiamato non è in grado di eseguire l'associazione del profilo Dialer
Se il nome utente autenticato non corrisponde al nome remoto del dialer configurato nell'interfaccia del dialer, la chiamata verrà disconnessa dal router chiamato. Di seguito è riportato un esempio di output del comando debug dialer per questo errore:
Sul router chiamante:
Il debug seguente mostra una disconnessione causata da un binding errato del profilo dialer sul router chiamato;
*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
Nota: I debug eseguiti dal dispositivo chiamato non sono utili per la risoluzione del problema, ad eccezione del fatto che il peer ha disconnesso la chiamata. Spostare la risoluzione dei problemi sul router chiamato.
Sul router chiamato:
Il debug seguente mostra che una chiamata non è riuscita a causa di problemi di associazione del profilo del dialer:
*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]
Soluzione:
Configurare il comando dialer pool number sull'interfaccia dialer. Il numero di pool deve corrispondere al numero di pool configurato nell'interfaccia fisica.
Configurare il comando dialer remote-name sull'interfaccia dialer. Il nome specificato deve corrispondere esattamente al nome utente fornito dal router remoto per l'autenticazione. In questo esempio, il nome utente autenticato è maui-soho-03.
Per ulteriori informazioni sulla risoluzione dei problemi relativi ai binding, consultare il documento sulla configurazione e la risoluzione dei problemi dei profili dialer.
È inoltre possibile utilizzare la Cisco Support Community per ulteriori operazioni di risoluzione dei problemi relativi al protocollo PPP.
Torna al diagramma di flusso per la risoluzione dei problemi
Problemi post-connessione
Sintomo: La chiamata si disconnette prematuramente o la chiamata non si disconnette affatto
Se la chiamata si disconnette in modo imprevisto o la chiamata non si disconnette mai, verificare il timeout di inattività della connessione e la definizione del traffico. È possibile usare il comando debug dialer packet per verificare se un pacchetto è interessante o meno. Ad esempio:
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)
Nell'esempio precedente, gli hellop OSPF non sono interessanti per access-list 101, mentre il secondo pacchetto è interessante per access-list 101.
- Regolare il timeout di inattività della connessione nella configurazione dell'interfaccia della connessione. L'impostazione predefinita è 120 secondi, ma è possibile aumentare o ridurre questo valore a seconda delle esigenze.
- Modificare la definizione del traffico interessante (configurata con il comando dialer-list). Se la chiamata si disconnette prematuramente, si potrebbe desiderare di definire il traffico interessante più liberamente. Se la chiamata non si disconnette mai, modificare la definizione del traffico interessante per essere più restrittiva. Ad esempio, è possibile definire il traffico del protocollo di routing come non interessante. Di seguito è riportato un esempio di definizione di traffico interessante:
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 1Per ulteriori informazioni, consultare il documento Tecnologia di connessione remota: Panoramiche e spiegazioni.
Sintomo: Il router chiama periodicamente la connessione
In alcune situazioni, è possibile notare che il router effettua periodicamente la connessione, anche se non è presente alcun traffico utente che richiede l'attivazione del collegamento. Questo può comportare costi di accesso elevati quando il servizio ISDN viene addebitato al minuto.
La causa più comune è che un processo che genera traffico periodico (come un protocollo di routing, ntp, snmp, ecc.) può essere inavvertitamente designato come interessante. La risoluzione di questo problema prevede due fasi:
- Identificare il traffico che causa la composizione del collegamento.
- Designate quel traffico come non interessante.
Identificare il traffico che causa il collegamento da comporre.
Per identificare il traffico che causa la composizione del collegamento, è necessario abilitare il pacchetto di debug dialer. Monitorare il router mentre il collegamento ISDN è inattivo e verificare la presenza di traffico periodico interessante che tenta di attivare il collegamento.
Suggerimento: A meno che non sia specificatamente necessario, designare tutti i protocolli di routing configurati sul router come non interessanti.
L'esempio seguente mostra gli hellop OSPF periodici contrassegnati come interessanti:
*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)
L'unico modo per identificare che il pacchetto di cui sopra è un hello OSPF è tramite l'indirizzo di destinazione (d=224.0.0.5) definito per OSPF. Nella tabella seguente vengono elencati gli indirizzi utilizzati per alcuni protocolli di routing comuni:
|
Protocollo di routing
|
Indirizzo di destinazione per periodico Aggiornamenti o Mantenimento attività |
|
RIPv1
|
255.255.255.255
|
|
RIPv2
|
224.0.0.9
|
|
EIGRP
|
224.0.0.10
|
|
OSPF
|
224.0.0.5
|
Il traffico che provoca la composizione del router (protocollo di routing o altro traffico periodico) deve essere contrassegnato come non interessante.
Designare il traffico periodico come non interessante
Modificare la definizione del traffico interessante (configurata con il comando dialer-list). In questo esempio, definire il traffico OSPF e NTP come non interessante. Di seguito è riportato un esempio di definizione di traffico interessante:
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
Per ulteriori informazioni, consultare il documento Tecnologia di connessione remota: Panoramiche e spiegazioni.
Nota: OSPF dispone di una funzionalità denominata circuito a richiesta che può essere utilizzata anche in questo caso. Per ulteriori informazioni, consultare il documento Perché il circuito di richiesta OSPF mantiene attivo il collegamento
Sintomo: Il secondo canale B non si connette
In molti casi, il router può connettersi solo a un canale B, mentre l'altro canale B rimane inattivo. Per ulteriori informazioni sulla risoluzione di questo problema, consultare il documento sulla risoluzione dei problemi relativi ai secondi errori di chiamata del canale B sui collegamenti ISDN BRI.
Problemi di connettività IP
Se il collegamento ISDN viene attivato ma non è possibile passare il traffico attraverso il collegamento, il problema è probabilmente un problema di routing o relativo a NAT. Per ulteriori informazioni sulla risoluzione dei problemi, fare riferimento alla Cisco Support Community.
Se si utilizza il collegamento ISDN come backup di una connessione WAN, consultare il documento relativo alla configurazione e alla risoluzione dei problemi di backup DDR.
Informazioni correlate
Feedback