Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Cronologia

Convenzioni

DDR Cisco IOS avvia la chiamata

Effettuare la chiamata

DDR modem asincrono esterno

DDR modem Async CAS T1/E1

PRI Async Modem DDR

BRI Async Modem DDR

PRI ISDN DDR

BRI ISDN DDR

Informazioni correlate

Introduzione

Questo documento illustra i metodi per la risoluzione dei problemi relativi ai diversi tipi di connessioni e non deve essere letto dall'inizio alla fine. La struttura è progettata per consentire al lettore di passare alle sezioni di interesse, ognuna delle quali rappresenta variazioni sul tema generale della risoluzione dei problemi per un caso specifico.

Prerequisiti

Requisiti

Questo documento copre tre scenari principali: prima di iniziare la risoluzione dei problemi, determinare il tipo di chiamata che si sta tentando di effettuare e passare alla sezione:

- Callin

- Routing su chiamata su richiesta (DDR) Cisco IOS

- Callout non DDR

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Cronologia

Dialup è semplicemente l'applicazione della rete telefonica pubblica commutata (PSTN) che trasporta i dati per conto dell'utente finale. Si tratta di un dispositivo CPE (Customer Premise Equipment) che invia all'interruttore telefonico un numero di telefono al quale indirizzare una connessione. AS3600, AS5200, AS5300 e AS5800 sono tutti esempi di router che possono eseguire un'interfaccia PRI (Primary Rate Interface) insieme a banchi di modem digitali. L'AS2511, d'altra parte, è un esempio di router che comunica con modem esterni.

Il mercato dei vettori è cresciuto in modo significativo e ora il mercato richiede densità di modem più elevate. La risposta a questa esigenza è una maggiore interazione con le apparecchiature della compagnia telefonica e lo sviluppo del modem digitale. Si tratta di un modem in grado di accedere direttamente alla rete PSTN. Di conseguenza, ora sono stati sviluppati modem CPE più veloci che sfruttano la chiarezza del segnale di cui godono i modem digitali. Il fatto che i modem digitali che si connettono alla PSTN tramite PRI o BRI (Basic Rate Interface) possano trasmettere i dati a più di 53k utilizzando lo standard di comunicazione V.90, dimostra il successo di questa idea.

I primi server di accesso sono stati AS2509 e AS2511. AS2509 poteva supportare 8 connessioni in ingresso utilizzando modem esterni e AS2511 poteva supportare 16. AS5200 è stato introdotto con 2 PRI e poteva supportare 48 utenti utilizzando modem digitali, rappresentando un importante passo avanti nella tecnologia. La densità dei modem è aumentata costantemente con l'AS5300 che supporta 4 e quindi 8 PRI. Infine, l'AS5800 è stato introdotto per soddisfare le esigenze delle installazioni di classe carrier che devono gestire decine di T1 in ingresso e centinaia di connessioni utente.

Un paio di tecnologie obsolete vengono menzionate in una discussione storica sulla tecnologia dialer. 56Kflex è un vecchio standard modem (precedente alla V.90) da 56k proposto da Rockwell. Cisco supporta la versione 1.1 dello standard 56Kflex sui modem interni, ma consiglia di migrare i modem CPE a V.90 il prima possibile. Un'altra tecnologia obsoleta è l'AS5100, una joint venture tra Cisco e un produttore di modem. L'AS5100 è stato creato per aumentare la densità del modem mediante l'uso di schede modem quadruple. Comprendeva un gruppo di AS2511 costruiti come schede inserite in un backplane condiviso da schede modem quadruple e una doppia scheda T1.

Convenzioni

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

DDR Cisco IOS avvia la chiamata

Mentre l'approccio per la risoluzione dei problemi delle chiamate in arrivo inizia in basso, la risoluzione dei problemi di una connessione in uscita inizia in alto.

Il ragionamento generale è simile al seguente:

1. Il routing DDR (Dial on Demand Routing) avvia una chiamata? La risposta affermativa consente di passare alla domanda successiva.

2. Se si tratta di un modem asincrono, gli script di chat eseguono i comandi previsti?

3. La chiamata arriva alla rete PSTN?

4. L'estremità remota risponde alla chiamata?

5. La chiamata è completata?

6. I dati passano attraverso il collegamento?

7. La sessione è stabilita? (PPP o terminale)

Per verificare se il dialer sta tentando di effettuare una chiamata alla destinazione remota, utilizzare il comando debug dialer events. È possibile ottenere informazioni più dettagliate dal pacchetto debug dialer, ma il comando debug dialer packet richiede molte risorse e non deve essere usato su un sistema occupato con più interfacce dialer in funzione.

La riga seguente dell'output degli eventi di debug dialer per un pacchetto IP elenca il nome dell'interfaccia DDR e gli indirizzi di origine e di destinazione del pacchetto:

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

Se il traffico non avvia un tentativo di composizione, la causa più comune è una configurazione errata (una delle definizioni di traffico interessanti, lo stato dell'interfaccia della connessione o il routing).

Tabella 1. Il traffico non avvia un tentativo di composizione

Possibili cause

Azioni consigliate

Definizioni di "traffico interessante" mancanti o errate

1. Utilizzando il comando show running-config, verificare che l'interfaccia sia configurata con un gruppo dialer e che sia presente un elenco di dialer a livello globale configurato con un numero corrispondente.

2. Verificare che il comando dialer-list sia configurato per autorizzare un intero protocollo o il traffico che corrisponde a un elenco degli accessi

3. Verificare che l'access-list dichiari interessanti i pacchetti che attraversano il collegamento. Un test utile è l'uso del comando exec privilegiato debug ip packet [list number] con il numero dell'elenco degli accessi pertinente. Quindi, provare a eseguire il ping sul collegamento, o inviare il traffico, attraverso di esso. Se i filtri del traffico interessati sono stati definiti correttamente, i pacchetti verranno visualizzati nell'output di debug. Se non è presente alcun output di debug da questo test, l'access-list non corrisponde ai pacchetti.

Stato interfaccia

Per verificare che l'interfaccia sia nello stato "up/up (spoofing)", usare il comando show interfaces <interface name>.

- Interfaccia in modalità "standby"

Un'altra interfaccia (primaria) sul router è stata configurata per usare l'interfaccia di connessione remota come interfaccia di backup. Inoltre, l'interfaccia primaria non si trova in uno stato di "down/down", che è necessario per far uscire l'interfaccia della connessione telefonica dalla modalità standby. Inoltre, è necessario configurare un ritardo di backup sull'interfaccia primaria, altrimenti il comando backup interface (interfaccia di backup) non verrà mai applicato. Per verificare che l'interfaccia della connessione telefonica passi da "standby" a "up/up (spoofing)", è in genere necessario estrarre il cavo dall'interfaccia primaria. Se si arresta l'interfaccia primaria con il comando di configurazione shutdown, l'interfaccia primaria non si arresta e non si spegne, ma viene messa "amministrativamente spenta"? non la stessa cosa. Inoltre, se la connessione primaria è tramite Frame Relay, la configurazione Frame Relay deve essere eseguita su un'interfaccia seriale point-to-point e la società telefonica deve passare il bit "Active". Questa procedura è nota anche come "LMI (Local Management Interface) end-to-end".

- Interfaccia "disattivata a livello amministrativo"

L'interfaccia della connessione remota è stata configurata con il comando shutdown. Questo è anche lo stato predefinito di qualsiasi interfaccia quando un router Cisco viene avviato per la prima volta. Per rimuovere questo ostacolo, usare il comando di configurazione interfaccia no shutdown.

Routing non corretto

Eseguire il comando exec show ip route [a.b.c.d], dove a.b.c.d è l'indirizzo dell'interfaccia di connessione del router remoto. se si usa ip senza numero sul router remoto, usare l'indirizzo dell'interfaccia elencata nel comando ip senza numero. L'output dovrebbe mostrare un percorso all'indirizzo remoto tramite l'interfaccia di connessione. Se non è disponibile alcuna route, verificare che le route statiche o flottanti siano state configurate esaminando l'output di show running-config. Se esiste un percorso tramite un'interfaccia diversa da quella dialer, l'implicazione è che il DDR viene utilizzato come backup. Esaminare la configurazione del router per verificare che siano state configurate route statiche o statiche mobili. Il modo più sicuro per verificare il routing, in questo caso, è disabilitare la connessione primaria ed eseguire il comando show ip route [a.b.c.d] per verificare che nella tabella di routing sia stata installata la route corretta.
Nota: se si tenta di eseguire questa operazione durante le operazioni di rete attive, potrebbe essere attivato un evento di composizione. Questo tipo di test può essere eseguito al meglio durante i cicli di manutenzione pianificati.

Effettuare la chiamata

Se il routing e i filtri del traffico interessanti sono corretti, avviare una chiamata. È possibile verificare questa condizione tramite gli eventi di debug dialer:

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

Async1 DDR: Attempting to dial 5551212

Se viene individuata la causa della chiamata ma non viene effettuato alcun tentativo di composizione, la causa più comune è una configurazione errata della mappa o del profilo della composizione.

Tabella 2. Chiamata non effettuata

Possibile problema

Azioni consigliate

Mapping dialer non configurato correttamente

Utilizzare il comando show running-config per verificare che l'interfaccia di composizione sia configurata con almeno un'istruzione dialer map che punti all'indirizzo di protocollo e al numero chiamato del sito remoto.

Profilo dialer non configurato correttamente

Utilizzare il comando show running-config per verificare che l'interfaccia dialer sia configurata con un comando dialer pool X e che l'interfaccia dialer sul router sia configurata con un membro corrispondente del pool dialer X. Se i profili dialer non sono configurati correttamente, è possibile che venga visualizzato un messaggio di debug del tipo:
Dialer1: Can't place call, no dialer pool set
Verificare che sia configurata una stringa di connessione.

Identificare quindi il tipo di supporto utilizzato:

- DDR per modem asincrono esterno

- DDR modem asincrono T1/E1 CAS (Channel Associated Signaling)

- DDR modem asincrono PRI

- DDR modem BRI asincrono

- PRI ISDN DDR

- BRI ISDN DDR

DDR modem asincrono esterno

1. Per identificare un DDR con modem asincrono esterno, utilizzare i comandi seguenti, quindi provare a effettuare una chiamata:

router# debug modem

router# debug chat line

2. Per le chiamate modem, è necessario eseguire uno script di chat affinché la chiamata possa continuare. Per il DDR basato su mappa dialer, lo script chat viene richiamato dal parametro modem-script in un comando mappa dialer. Se il DDR è basato sul profilo dialer, ciò avviene mediante lo script di comando dialer, configurato sulla riga TTY. Entrambi i metodi si basano su uno script di chat esistente nella configurazione globale del router, ad esempio:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In entrambi i casi, il comando per visualizzare l'attività dello script di chat è debug chat. Se la stringa di composizione, ovvero il numero di telefono, utilizzata nel comando dialer map o dialer string è 5551212, l'output del comando debug sarà simile al seguente:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Verificare che lo script di chat tenti la chiamata prevista, ovvero il numero corretto, in base alla stringa di invio. Se lo script di chat non tenta di effettuare la chiamata prevista, verificare la configurazione dello script di chat. Utilizzare il comando start-chat al prompt di exec per avviare manualmente lo script di chat.

4. Visualizzazione di "Timeout previsto: CONNECT" può descrivere diverse possibilità:

- Possibilità 1: Il modem locale non effettua la chiamata. Verificare che il modem sia in grado di effettuare una chiamata eseguendo una connessione telnet inversa al modem e avviando manualmente una composizione. Se l'estremità remota non sembra rispondere, verificare che la chiamata sia stata effettuata dal modem di origine chiamando manualmente un numero locale con il comando ATDT <number> e ascoltando il ring.

- Possibilità 2: Il modem remoto non risponde. Per verificarlo, comporre il modem remoto con un normale telefono POTS. Combinazione di tasti:

1. Verificare che il numero di telefono chiamato sia corretto. Utilizzare un ricevitore per chiamare il numero di ricezione. Accertarsi di utilizzare lo stesso cavo per la parete utilizzato dal modem. Se una chiamata manuale è in grado di raggiungere il modem asincrono ricevente, il modem di origine potrebbe non funzionare correttamente. Verificare il modem e sostituirlo se necessario.

2. Se una chiamata manuale non è in grado di raggiungere il modem asincrono ricevente, modificare i cavi telefonici del modem ricevente e provare a utilizzare un normale telefono sulla linea del modem ricevente. Se la chiamata può essere ricevuta dal normale telefono, è probabile che vi sia un problema con il modem ricevente.

3. Se la chiamata manuale non è ancora in grado di raggiungere il telefono normale sulla linea in questione, provare a utilizzare un'altra linea (funzionante) nella struttura di ricezione. Se il collegamento è corretto, controllare la linea telefonica del modem ricevente.

4. Se si tratta di una chiamata interurbana, chiedere al mittente di provare un altro numero (valido) di chiamata interurbana. Se funziona, l'impianto o la linea ricevente potrebbero non essere predisposti per ricevere chiamate interurbane. Se la linea di origine non è in grado di raggiungere altri numeri per chiamate interurbane, è possibile che non sia attivata la modalità interurbane. Prova i codici 1010 per diverse società di telefonia fissa.

5. Infine, provare un altro numero locale (valido) dalla riga di origine. Se la connessione continua a non riuscire, chiedere al telco di controllare la linea di origine.

- Possibilità 3: Il numero composto non è corretto. Verificare il numero componendolo manualmente. Se necessario, correggere la configurazione.

- Possibilità 4: L'addestramento del modem richiede troppo tempo o il valore di TIMEOUT è troppo basso. Provare ad aumentare il valore TIMEOUT nel comando chat-script. Se il valore di TIMEOUT è già pari a 60 secondi o superiore, potrebbe essersi verificato un problema di cablaggio tra il modem e il DTE a cui è collegato. I guasti del training possono anche indicare un problema di circuito o l'incompatibilità del modem.

Per arrivare alla fine di un problema del singolo modem, andare al prompt AT sul modem di origine con reverse telnet. Se possibile, accedere anche al prompt AT del modem ricevente. La maggior parte dei modem indica un anello alla sessione terminale collegata alla connessione DTE. Utilizzare ATM1 per fare in modo che il modem invii suoni al proprio altoparlante in modo che le persone a ciascuna estremità possano sentire ciò che accade sulla linea.

La musica è rumorosa? In tal caso, pulire il circuito. Se i modem asincroni non si allenano, chiamare il numero e ascoltare la musica statica. Ci possono essere altri fattori che interferiscono con il treno verso l'alto. Invertire il protocollo telnet sul modem asincrono ed eseguire il debug.

5. Se tutto funziona correttamente e non è ancora possibile connettersi al DDR del modem ASINC CAS, provare a eseguire il debug PPP. Utilizzare i comandi:

router# debug ppp negotiation

router# debug ppp authentication

Se lo script di chat viene completato correttamente, i modem sono connessi. Consultare la sezione "Risoluzione dei problemi PPP" nel capitolo 17 della Guida per la risoluzione dei problemi di rete per il passaggio successivo nella risoluzione dei problemi di connessione.

DDR modem Async CAS T1/E1

1. Per identificare un DDR per modem asincrono CAS T1/E1, utilizzare i comandi seguenti, quindi provare a effettuare una chiamata:

Avviso:  L'esecuzione dei debug su un sistema occupato potrebbe causare un arresto anomalo del router con sovraccarico della CPU o sovraccarico del buffer della console.

router# debug modem

router# debug chat or debug chat line n

router# debug modem csm

router# debug cas

Nota: il comando debug cas è disponibile sulle piattaforme Cisco AS5200 e AS5300 con Cisco IOS?? Software release 12.0(7)T e successive. Nelle versioni precedenti di IOS, il comando service internal deve essere immesso nel livello principale della configurazione del router e il comando modem-mgmt csm debug-rbs deve essere immesso al prompt di exec. Il debug su Cisco AS5800 richiede la connessione alla scheda trunk. Per disattivare il debug, usare modem-mgmt csm no-debug-rbs.

2. Per le chiamate modem, è necessario eseguire uno script di chat affinché la chiamata possa continuare. Per il DDR basato su mappa dialer, lo script chat viene richiamato dal parametro modem-script in un comando mappa dialer. Se il DDR è basato sul profilo dialer, ciò avviene mediante lo script di comando dialer, configurato sulla riga TTY. Entrambi gli utenti si basano su uno script di chat esistente nella configurazione globale del router, ad esempio:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In entrambi i casi, il comando per visualizzare l'attività dello script di chat è debug chat. Se la stringa di composizione, ovvero il numero di telefono, utilizzata nel comando dialer map o dialer string è 5551212, l'output del comando debug sarà simile al seguente:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Verificare che lo script di chat tenti la chiamata prevista (ovvero il numero corretto) in base alla stringa di invio. Se lo script di chat non tenta di effettuare la chiamata prevista, verificare la configurazione dello script di chat. Utilizzare il comando start-chat al prompt di exec per avviare manualmente lo script di chat.

4. Visualizzazione di "Timeout previsto: CONNECT" può descrivere diverse possibilità:

- Possibilità 1: Il modem locale non effettua la chiamata. Verificare che il modem sia in grado di effettuare una chiamata eseguendo una connessione Telnet inversa al modem e avviando manualmente una composizione. Se l'estremità remota non sembra rispondere, verificare che la chiamata sia stata effettuata dal modem chiamando manualmente un numero locale con il comando ATDT<number> e ascoltando la chiamata.

Per le chiamate in uscita tramite CAS T1 o E1 e i modem digitali integrati, gran parte della risoluzione dei problemi è simile ad altre operazioni di risoluzione dei problemi DDR. Lo stesso vale anche per le chiamate modem integrate in uscita su una linea PRI. Le funzionalità univoche di una chiamata di questo tipo richiedono un debug speciale in caso di errore della chiamata.

Come per altre situazioni DDR, è necessario verificare che sia richiesto un tentativo di chiamata. A tale scopo, utilizzare gli eventi dialer di debug. Fare riferimento a DDR IOS più indietro in questo articolo.

Prima di poter effettuare una chiamata, è necessario allocare un modem per la chiamata. Per visualizzare questo processo e la chiamata successiva, utilizzare i comandi di debug seguenti:

router# debug modem

router# debug modem csm

router# debug cas

Nota: il comando debug cas è apparso per la prima volta in IOS versione 12.0(7)T per AS5200 e AS5300. Le versioni precedenti di IOS usano un servizio interno di comandi di configurazione a livello di sistema insieme al comando exec modem-mgmt debug rbs:

Attivazione dei debug:

router#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

router(config)#service internal

router(config)#^Z

router#modem-mgmt csm ?

debug-rbs     enable rbs debugging

no-debug-rbs  disable rbs debugging

router#modem-mgmt csm debug-rbs

router#

neat msg at slot 0: debug-rbs is on

neat msg at slot 0: special debug-rbs is on

Disattivazione dei debug:

router#modem-mgmt csm no-debug-rbs

neat msg at slot 0: debug-rbs is off

Il debug di queste informazioni su un AS5800 richiede la connessione alla scheda trunk. Di seguito è riportato un esempio di una normale chiamata in uscita su un server CAS T1 con provisioning e configurazione per FXS-Ground-Start:

Mica Modem(1/0): Rcvd Dial String(5551111)

[Modem receives digits from chat script]

CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):

EVENT_CHANNEL_LOCK at slot 1 and port 0

CSM_PROC_OC4_DIALING:

CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0

Mica Modem(1/0): Configure(0x1)

Mica Modem(1/0): Configure(0x2)

Mica Modem(1/0): Configure(0x5)

Mica Modem(1/0): Call Setup

neat msg at slot 0: (0/2): Tx RING_GROUND

Mica Modem(1/0): State Transition to Call Setup

neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING

[Telco switch goes OFFHOOK]

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):

EVENT_START_TX_TONE at slot 1 and port 0

CSM_PROC_OC5_WAIT_FOR_CARRIER:

CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0

neat msg at slot 0: (0/2):

Tx LOOP_CLOSURE [Now the router goes OFFHOOK]

Mica Modem(1/0): Rcvd Tone detected(2)

Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8

Mica Modem(1/0): Rcvd Digits Generated

CSM_PROC_OC5_WAIT_FOR_CARRIER:

CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):

EVENT_CHANNEL_CONNECTED at slot 1 and port 0

CSM_PROC_OC5_WAIT_FOR_CARRIER:

CSM_EVENT_DSX0_CONNECTED at slot 1, port 0

Mica Modem(1/0): Link Initiate

Mica Modem(1/0): State Transition to Connect

Mica Modem(1/0): State Transition to Link

Mica Modem(1/0): State Transition to Trainup

Mica Modem(1/0): State Transition to EC Negotiating

Mica Modem(1/0): State Transition to Steady State

Mica Modem(1/0): State Transition to Steady State Speedshifting

Mica Modem(1/0): State Transition to Steady State

I debug per T1 ed E1 con altri tipi di segnalazione sono simili.

Raggiungere questo punto del debug indica che i modem chiamanti e rispondenti sono stati addestrati e connessi e che i protocolli di livello superiore possono iniziare a negoziare. Se un modem è allocato correttamente per la chiamata in uscita ma la connessione non riesce a raggiungere tale punto, è necessario esaminare il T1. Utilizzare il comando show controller t1/e1 per verificare che T1/E1 funzioni. Vedere Risoluzione dei problemi delle linee seriali per una spiegazione dell'output del comando show controller. Se T1/E1 non funziona correttamente, è necessaria la risoluzione dei problemi di T1/E1.

- Possibilità 2: Il modem remoto non risponde. Verificare questa condizione chiamando il modem remoto con un normale telefono. Combinazione di tasti:

1. Verificare che il numero di telefono chiamato sia corretto. Utilizzare un ricevitore per chiamare il numero di ricezione.

2. Accertarsi che una chiamata manuale sia in grado di raggiungere il modem asincrono che risponde. Se una chiamata manuale è in grado di raggiungere il modem asincrono per la risposta, è possibile che la linea CAS non venga attivata per consentire le chiamate vocali in uscita.

3. Se una chiamata manuale non è in grado di raggiungere il modem asincrono ricevente, modificare i cavi telefonici del modem ricevente e provare a utilizzare un normale telefono sulla linea del modem ricevente. Se la chiamata può essere ricevuta dal normale telefono, è probabile che vi sia un problema con il modem ricevente.

4. Se la chiamata manuale non è ancora in grado di raggiungere il telefono normale sulla linea in questione, provare a utilizzare un'altra linea (funzionante) nella struttura di ricezione. Se il collegamento viene effettuato, chiedere al telefono di controllare la linea telefonica del modem ricevente.

5. Se si tratta di una chiamata interurbana, chiedere al mittente di provare un altro numero (valido) di chiamata interurbana. In tal caso, l'impianto o la linea ricevente potrebbero non essere predisposti per ricevere chiamate interurbane. Se la linea di origine (CAS) non è in grado di raggiungere altri numeri per chiamate interurbane, è possibile che non sia abilitata la comunicazione interurbana. Prova 10-10 codici per diverse società di telefonia fissa.

6. Infine, provare un altro numero locale (valido) dalla riga CAS di origine. Se la connessione continua a non riuscire, chiedere a telco di controllare il server CAS.

- Possibilità 3: Il numero composto non è corretto. Verificare il numero componendolo manualmente. Se necessario, correggere la configurazione.

- Possibilità 4: Il training del modem sta impiegando troppo tempo o il valore di TIMEOUT è troppo basso. Provare ad aumentare il valore TIMEOUT nel comando chat-script. Se il valore di TIMEOUT è già pari a 60 secondi o superiore, potrebbe essersi verificato un problema di cablaggio tra il modem e il DTE a cui è collegato. I guasti del training possono anche indicare un problema di circuito o l'incompatibilità del modem.

Per arrivare alla fine di un problema del singolo modem, andare al prompt AT sul modem di origine con reverse telnet. Se possibile, utilizzare il comando reverse telnet per accedere anche al prompt AT del modem ricevente. Utilizzare ATM1 per fare in modo che il modem invii suoni al proprio altoparlante in modo che le persone a ciascuna estremità possano sentire ciò che accade sulla linea.

La musica è rumorosa? In tal caso, pulire il circuito. Se i modem asincroni non si allenano, chiamare il numero e ascoltare la musica statica. Ci possono essere altri fattori che interferiscono con il treno verso l'alto. Invertire Telnet sul modem asincrono e quindi eseguire il debug.

5. Se tutto funziona correttamente e non è ancora possibile connettersi al DDR del modem ASINC CAS, provare a eseguire il debug PPP. Se lo script di chat viene completato correttamente e i debug PPP indicano un errore, consultare la sezione "Risoluzione dei problemi PPP" nel capitolo 17 della Guida per la risoluzione dei problemi di Internet.

PRI Async Modem DDR

1. Per identificare un DDR con modem PRI asincrono, utilizzare i seguenti comandi, quindi provare a effettuare una chiamata:

Avviso:  L'esecuzione dei debug su un sistema occupato potrebbe causare un arresto anomalo del router con sovraccarico della CPU o sovraccarico del buffer della console.

router# debug modem

router# debug chat

router# debug modem csm

router# debug isdn q931

router# debug isdn

router# debug ppp negotiate

router# debug ppp authenticate

2. Per le chiamate modem, è necessario eseguire uno script di chat affinché la chiamata possa continuare. Per il DDR basato su mappa dialer, lo script chat viene richiamato dal parametro modem-script in un comando mappa dialer. Se il DDR è basato sul profilo dialer, ciò avviene mediante lo script di comando dialer, configurato sulla riga TTY. Entrambi i metodi si basano su uno script di chat esistente nella configurazione globale del router, ad esempio:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In entrambi i casi, il comando per visualizzare l'attività dello script di chat è debug chat. Se la stringa di composizione (numero di telefono) utilizzata nel comando dialer map o dialer string è 5551212, l'output del comando debug sarà simile al seguente:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Verificare che lo script di chat tenti la chiamata prevista (il numero corretto) in base alla stringa di invio. Se lo script di chat non tenta di effettuare la chiamata prevista, verificare la configurazione dello script di chat. Utilizzare il comando start-chat al prompt di exec per avviare manualmente lo script di chat.

4. Visualizzazione di "Timeout previsto: CONNECT" può descrivere diverse possibilità:

- Possibilità 1: Il modem locale non effettua la chiamata. Verificare che il modem sia in grado di effettuare una chiamata eseguendo una connessione telnet inversa al modem e avviando manualmente una composizione. Se l'estremità remota non sembra rispondere, verificare che la chiamata sia stata effettuata dal modem chiamando manualmente un numero locale con il comando ATDT<number> e ascoltando la chiamata. Se non viene effettuata alcuna chiamata, attivare i debug ISDN. In caso di primo sospetto di errore ISDN su un BRI, controllare sempre l'output del comando show isdn status. È importante notare che il livello 1 deve essere Attivo e il livello 2 deve essere nello stato MULTIPLE_FRAME_DEFINED. Vedere la Internetwork Troubleshooting Guide, capitolo 16, "Interpreting Show ISDN Status" per informazioni sulla lettura di questo output, nonché per le misure correttive.

Per le chiamate ISDN in uscita, gli eventi debug isdn q931 e debug isdn sono gli strumenti migliori da utilizzare. Fortunatamente, il debug delle chiamate in uscita è molto simile al debug delle chiamate in arrivo. Una normale chiamata riuscita potrebbe avere il seguente aspetto:

*Mar 20 21:07:45.025: ISDN SE0:23: Event:

Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8

callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8

callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8

callref = 0xAC

*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

Il messaggio CONNECT è l'indicatore chiave del successo. Se non si riceve un messaggio CONNECT, è possibile che venga visualizzato un messaggio DISCONNECT o RELEASE_COMP (rilascio completato) seguito da un codice causa:

*Mar 20 22:11:03.212: ISDN SE0:23:

RX <-RELEASE_COMP pd = 8 callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

Il valore della causa indica due elementi:

- Il secondo byte del valore a 4 o 6 byte indica il punto nel percorso della chiamata end-to-end da cui è stata ricevuta la richiesta DISCONNECT o RELEASE_COMP. In questo modo è possibile localizzare il problema.

- Il terzo e il quarto byte indicano la causa effettiva dell'errore. Per il significato dei diversi valori, vedere la Tabella 9.

- Possibilità 2: Il modem remoto non risponde. Verificare questa condizione chiamando il modem remoto con un normale telefono. Combinazione di tasti:

1. Verificare che il numero di telefono chiamato sia corretto. Utilizzare un ricevitore per chiamare il numero di ricezione.

2. Accertarsi che una chiamata manuale sia in grado di raggiungere il modem asincrono che risponde. Se una chiamata manuale è in grado di raggiungere il modem asincrono di risposta, la linea BRI potrebbe non essere predisposta per consentire le chiamate vocali in uscita.

3. Se una chiamata manuale non è in grado di raggiungere il modem asincrono ricevente, modificare i cavi telefonici del modem ricevente e provare a utilizzare un normale telefono sulla linea del modem ricevente. Se la chiamata può essere ricevuta dal normale telefono, è probabile che vi sia un problema con il modem ricevente.

4. Se la chiamata manuale non è ancora in grado di raggiungere il telefono normale sulla linea in questione, provare a utilizzare un'altra linea (funzionante) nella struttura di ricezione. Se il collegamento viene effettuato, chiedere al telefono di controllare la linea telefonica del modem ricevente.

5. Se si tratta di una chiamata interurbana, chiedere al mittente di provare un altro numero (valido) di chiamata interurbana. Se funziona, l'impianto o la linea ricevente potrebbero non essere predisposti per ricevere chiamate interurbane. Se la linea di origine (BRI) non è in grado di raggiungere altri numeri interurbani, è possibile che non sia attivata la modalità interurbana. Prova i codici 1010 per diverse società di telefonia fissa.

6. Infine, provare un altro numero locale (valido) dalla riga BRI di origine. Se la connessione non riesce, chiedere al telco di controllare la BRI.

- Possibilità 3: Il numero composto non è corretto. Verificare il numero componendolo manualmente. Se necessario, correggere la configurazione.

- Possibilità 4: L'addestramento del modem richiede troppo tempo o il valore di TIMEOUT è troppo basso. Provare ad aumentare il valore TIMEOUT nel comando chat-script. Se il valore di TIMEOUT è già pari a 60 secondi o superiore, potrebbe essersi verificato un problema di cavi tra il modem e il DTE a cui è collegato. I guasti del training possono anche indicare un problema di circuito o l'incompatibilità del modem.

Per arrivare alla fine di un problema del singolo modem, andare al prompt AT sul modem di origine con reverse telnet. Se possibile, utilizzare il comando reverse telnet per accedere anche al prompt AT del modem ricevente. Utilizzare ATM1 per fare in modo che il modem invii suoni al proprio altoparlante in modo che le persone a ciascuna estremità possano sentire ciò che accade sulla linea.

La musica è rumorosa? In tal caso, pulire il circuito. Se i modem asincroni non si allenano, chiamare il numero e ascoltare la musica statica. Ci possono essere altri fattori che interferiscono con il treno verso l'alto. Invertire Telnet sul modem asincrono e quindi eseguire il debug.

5. Se tutto funziona correttamente e non è ancora possibile connettersi al DDR del modem asincrono BRI, provare il debug PPP. Se lo script di chat viene completato correttamente e i debug PPP indicano un errore, consultare la sezione "Risoluzione dei problemi PPP" nel capitolo 17 della Guida per la risoluzione dei problemi di Internet.

BRI Async Modem DDR

Questa funzione funziona solo sulla piattaforma Cisco 3640 con software Cisco IOS versione 12.0(3)T o successive. Richiede una revisione hardware successiva del modulo di rete BRI. Ciò non è possibile con una scheda di interfaccia WAN (WIC).

1. Verificare che il codice del paese sia corretto con il comando show modem. Utilizzare i seguenti comandi, quindi provare a effettuare una chiamata:

Avviso:  L'esecuzione dei debug su un sistema occupato potrebbe causare un arresto anomalo del router con sovraccarico della CPU o sovraccarico del buffer della console.

router# debug modem

router# debug chat

router# debug modem csm

router# debug isdn q931

router# debug bri

router# debug ppp negotiate

router# debug ppp authenticate

2. Per le chiamate modem, è necessario eseguire uno script di chat affinché la chiamata possa continuare. Per il DDR basato su mappa dialer, lo script di chat viene richiamato dal parametro modem-script in un comando mappa dialer. Se il DDR è basato sul profilo dialer, ciò avviene mediante lo script di comando dialer, configurato sulla riga TTY. Entrambi gli utenti si basano su uno script di chat esistente nella configurazione globale del router, ad esempio:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In entrambi i casi, il comando per visualizzare l'attività dello script di chat è debug chat. Se la stringa di composizione (numero di telefono) utilizzata nel comando dialer map o dialer string è 5551212, l'output del comando debug sarà simile al seguente:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Verificare che lo script di chat tenti la chiamata prevista (il numero corretto) in base alla stringa di invio. Se lo script di chat non tenta di effettuare la chiamata prevista, verificare la configurazione dello script di chat. Utilizzare il comando start-chat al prompt di exec per avviare manualmente lo script di chat.

4. Visualizzazione di "Timeout previsto: CONNECT" può descrivere diverse possibilità:

- Possibilità 1: Il modem locale non effettua la chiamata. Verificare che il modem sia in grado di effettuare una chiamata eseguendo una connessione telnet inversa al modem e avviando manualmente una composizione. Se l'estremità remota non sembra rispondere, verificare che la chiamata sia stata effettuata dal modem chiamando manualmente un numero locale con il comando ATDT<number> e ascoltando la chiamata. Se non viene effettuata alcuna chiamata, attivare i debug ISDN. In caso di primo sospetto di errore ISDN su un BRI, controllare sempre l'output del comando show isdn status. È importante notare che il livello 1 deve essere Attivo e il livello 2 deve essere nello stato MULTIPLE_FRAME_DEFINED. Per informazioni sulla lettura di questo output e sulle misure correttive, consultare il capitolo 16, "Interpreting Show ISDN Status" della Internetwork Troubleshooting Guide.

Per le chiamate ISDN in uscita, gli eventi debug isdn q931 e debug isdn sono gli strumenti migliori da utilizzare. Fortunatamente, il debug delle chiamate in uscita è molto simile al debug delle chiamate in arrivo. Una normale chiamata riuscita potrebbe avere il seguente aspetto:

*Mar 20 21:07:45.025: ISDN BR0: Event:

Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8

callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8

callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8

callref = 0xAC

*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

Il messaggio CONNECT è l'indicatore chiave del successo. Se non si riceve un messaggio CONNECT, è possibile che venga visualizzato un messaggio DISCONNECT o RELEASE_COMP (rilascio completato) seguito da un codice causa:

*Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8

callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

Il valore della causa indica due cose.

- Il secondo byte del valore a 4 o 6 byte indica il punto nel percorso della chiamata end-to-end da cui è stata ricevuta la richiesta DISCONNECT o RELEASE_COMP. In questo modo è possibile localizzare il problema.

- Il terzo e il quarto byte indicano la causa effettiva dell'errore. Per il significato dei diversi valori, vedere la Tabella 9.

- Possibilità 2: Il modem remoto non risponde. Verificare questa condizione chiamando il modem remoto con un normale telefono. Combinazione di tasti:

1. Verificare che il numero di telefono chiamato sia corretto. Utilizzare un ricevitore per chiamare il numero di ricezione.

2. Accertarsi che una chiamata manuale sia in grado di raggiungere il modem asincrono che risponde. Se una chiamata manuale è in grado di raggiungere il modem asincrono di risposta, la linea BRI potrebbe non essere predisposta per consentire le chiamate vocali in uscita.

3. Se una chiamata manuale non è in grado di raggiungere il modem asincrono ricevente, modificare i cavi telefonici del modem ricevente e provare a utilizzare un normale telefono sulla linea del modem ricevente. Se la chiamata può essere ricevuta dal normale telefono, è probabile che vi sia un problema con il modem ricevente.

4. Se la chiamata manuale non è ancora in grado di raggiungere il telefono normale sulla linea in questione, provare a utilizzare un'altra linea (funzionante) nella struttura di ricezione. Se il collegamento viene effettuato, chiedere al telefono di controllare la linea telefonica del modem ricevente.

5. Se si tratta di una chiamata interurbana, chiedere al mittente di provare un altro numero (valido) di chiamata interurbana. Se funziona, l'impianto o la linea ricevente potrebbero non essere predisposti per ricevere chiamate interurbane. Se la linea di origine (BRI) non è in grado di raggiungere altri numeri interurbani, è possibile che non sia attivata la modalità interurbana. Prova 10-10 codici per diverse società di telefonia fissa.

6. Infine, provare un altro numero locale (valido) dalla riga BRI di origine. Se la connessione non riesce, chiedere al telco di controllare la BRI.

- Possibilità 3: Il numero composto non è corretto. Verificare il numero componendolo manualmente. Se necessario, correggere la configurazione.

- Possibilità 4: Il training del modem sta impiegando troppo tempo o il valore di TIMEOUT è troppo basso. Provare ad aumentare il valore TIMEOUT nel comando chat-script. Se il valore di TIMEOUT è già pari a 60 secondi o superiore, potrebbe essersi verificato un problema di cavi tra il modem e il DTE a cui è collegato. I guasti del training possono anche indicare un problema di circuito o l'incompatibilità del modem.

Per arrivare alla fine di un problema del singolo modem, andare al prompt AT sul modem di origine con reverse telnet. Se possibile, utilizzare il comando reverse telnet per accedere anche al prompt AT del modem ricevente. Utilizzare ATM1 per fare in modo che il modem invii suoni al proprio altoparlante in modo che le persone a ciascuna estremità possano sentire ciò che accade sulla linea.

La musica è rumorosa? In tal caso, pulire il circuito. Se i modem asincroni non si allenano, chiamare il numero e ascoltare la musica statica. Ci possono essere altri fattori che interferiscono con il treno verso l'alto. Invertire Telnet sul modem asincrono e quindi eseguire il debug.

5. Se tutto funziona correttamente e non è ancora possibile connettersi al DDR del modem asincrono BRI, provare il debug PPP. Se lo script di chat viene completato correttamente e i debug PPP indicano un errore, consultare la sezione "Risoluzione dei problemi PPP" nel capitolo 17 della Guida per la risoluzione dei problemi di Internet.

PRI ISDN DDR

1. In caso di primo sospetto di errore ISDN su un sistema PRI, controllare sempre l'output del comando show isdn status. È importante notare che il livello 1 deve essere Attivo e il livello 2 deve essere nello stato MULTIPLE_FRAME_DEFINED. Per informazioni sulla lettura di questo output e sulle misure correttive, consultare il capitolo 16, "Interpreting Show ISDN Status" della Internetwork Troubleshooting Guide.

Per le chiamate ISDN in uscita, gli eventi debug isdn q931 e debug isdn sono gli strumenti migliori da utilizzare. Fortunatamente, il debug delle chiamate in uscita è molto simile al debug delle chiamate in arrivo. Una normale chiamata riuscita potrebbe avere il seguente aspetto:

*Mar 20 21:07:45.025: ISDN SE0:23: Event:

Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8

callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8

callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8

callref = 0xAC

*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

Il messaggio CONNECT è l'indicatore chiave del successo. Se non si riceve un messaggio CONNECT, è possibile che venga visualizzato un messaggio DISCONNECT o RELEASE_COMP (rilascio completato) seguito da un codice causa:

*Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8

callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

Il valore della causa indica due cose.

- Il secondo byte del valore a 4 o 6 byte indica il punto nel percorso della chiamata end-to-end da cui è stata ricevuta la richiesta DISCONNECT o RELEASE_COMP. In questo modo è possibile localizzare il problema.

- Il terzo e il quarto byte indicano la causa effettiva dell'errore. Per il significato dei diversi valori, vedere la Tabella 9.

Nota: la seguente immagine indica un errore di protocollo superiore:

Cause i = 0x8090 - Normal call clearing

Un errore di autenticazione PPP è in genere dovuto a un errore. Attivare la negoziazione ppp di debug e l'autenticazione ppp di debug prima di presupporre che l'errore di connessione sia necessariamente un problema ISDN.

2. Se viene visualizzato il messaggio ISDN CONNECT e i debug PPP indicano un errore, consultare la sezione "Risoluzione dei problemi PPP" nel capitolo 17 della Guida per la risoluzione dei problemi di interrete.

BRI ISDN DDR

1. In caso di primo sospetto di errore ISDN su un BRI, controllare sempre l'output del comando show isdn status. È importante notare che il livello 1 deve essere Attivo e il livello 2 deve essere nello stato MULTIPLE_FRAME_DEFINED. Per informazioni sulla lettura di questo output e sulle misure correttive, vedere il capitolo 16 della Guida alla risoluzione dei problemi di Internetwork, "Interpreting Show ISDN Status" (Interpretazione dello stato ISDN).

Per le chiamate ISDN in uscita, gli eventi debug isdn q931 e debug isdn sono gli strumenti migliori da utilizzare. Fortunatamente, il debug delle chiamate in uscita è molto simile al debug delle chiamate in arrivo. Una normale chiamata riuscita potrebbe avere il seguente aspetto:

*Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC

*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

Il messaggio CONNECT è l'indicatore chiave del successo. Se non si riceve un messaggio CONNECT, è possibile che venga visualizzato un messaggio DISCONNECT o RELEASE_COMP (rilascio completato) seguito da un codice causa:

*Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8

callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

Il valore della causa indica due cose.

- Il secondo byte del valore a 4 o 6 byte indica il punto nel percorso della chiamata end-to-end da cui è stata ricevuta la richiesta DISCONNECT o RELEASE_COMP. In questo modo è possibile localizzare il problema.

- Il terzo e il quarto byte indicano la causa effettiva dell'errore. Per il significato dei diversi valori, vedere la Tabella 9.

Nota: la seguente immagine indica un errore di protocollo superiore:

Cause i = 0x8090 - Normal call clearing

Un errore di autenticazione PPP è in genere dovuto a un errore. Attivare la negoziazione ppp di debug e l'autenticazione ppp di debug prima di presupporre che l'errore di connessione sia necessariamente un problema ISDN.

2. Se viene visualizzato il messaggio ISDN CONNECT e i debug PPP indicano un errore, consultare la sezione "Risoluzione dei problemi PPP" nel capitolo 17 della Guida per la risoluzione dei problemi di interrete.

Informazioni correlate

- Guida alla configurazione rapida di Cisco IOS Dial Services

- Guida alla configurazione di Cisco IOS Dial Services: Servizi di rete

- Guida alla configurazione di Cisco IOS Dial Services: Servizi terminal

- Guida di riferimento ai comandi di Cisco IOS Dial Services

- Panoramica del Dial Case Study

- Accedi alle pagine sulle tecnologie

- Documentazione e supporto tecnico – Cisco Systems