Risoluzione dei problemi di connettività della tecnologia di composizione - Il DDR IOS avvia la chiamata

Opzioni per il download

  • PDF     (217.2 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (99.7 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (108.5 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:9 luglio 2007
ID documento:14954

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

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:

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 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:

    warning 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:

    warning 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:

    warning 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

Cronologia delle revisioni

Revisione Data di pubblicazione Commenti
1.0
09-Jul-2007
Versione iniziale

Questo documento ti è stato utile?

FeedbackFeedback

Contattaci