Risoluzione dei problemi della linea seriale

Introduzione

In questo capitolo vengono fornite informazioni generali sulla risoluzione dei problemi e viene fornita una descrizione degli strumenti e delle tecniche per la risoluzione dei problemi relativi alle connessioni seriali. Il capitolo è costituito dalle seguenti sezioni:

• Risoluzione dei problemi con il comando show interfaces serial

• Uso del comando show controllers

• Uso dei comandi di debug

• Uso dei test ping estesi

• Risoluzione dei problemi di clock

• Adeguamento dei buffer

• Test speciali della linea seriale

• Informazioni dettagliate sul comando show interfaces serial

• Risoluzione dei problemi T1

• Risoluzione dei problemi E1

Prerequisiti

Requisiti

I lettori di questo documento devono essere a conoscenza delle seguenti definizioni.

• DTE = apparecchiature terminali dati

• CD = Rilevamento portante

• CSU = channel service unit

• DSU = Digital Service Unit

• SCTE = trasmissione seriale orologio esterna

• DCE = apparecchiature di terminazione di circuiti dati

• CTS = clear-to-send

• DSR = pronto per data set

• SAP = Service Advertising Protocol

• IPX = Internetwork Packet Exchange

• FDDI = Fiber Distributed Data Interface

• ESF = formato esteso superframe

• B8ZS = sostituzione binaria otto-zero

• LBO = Uscita linea

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.

Convenzioni

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

Risoluzione dei problemi con il comando show interfaces serial

L'output del comando show interfaces serial EXEC visualizza informazioni specifiche sulle interfacce seriali. La Figura 15-1 mostra l'output del comando show interfaces serial EXEC per un'interfaccia seriale HDLC (High-Level Data Link Control).

In questa sezione viene descritto come usare il comando show interfaces serial per diagnosticare i problemi di connettività della linea seriale in un ambiente WAN (Wide Area Network). Nelle sezioni seguenti vengono descritti alcuni dei campi importanti dell'output del comando.

Gli altri campi visualizzati sono descritti in dettaglio nella sezione "Informazioni dettagliate sul comando show interfaces serial" più avanti in questo capitolo.

Linee seriali: show interfaces serial Status Line Condizioni

È possibile identificare cinque possibili stati di problema nella riga di stato dell'interfaccia del display seriale show interfaces (vedere la Figura 15-1):

• Serial x non attivo, protocollo di linea non attivo

• Serial x attivo, protocollo di linea inattivo

• Serial x attivo, protocollo di linea attivo (a ciclo continuo)

• Serial x attivo, protocollo di linea inattivo (disabilitato)

• Serial x disattivato a livello amministrativo, protocollo di linea disattivato

Figura 15-1 Output del comando seriale HDLC show interface

Tabella 15-1: Linee seriali: show interfaces serial Status Line Conditions: questa tabella mostra le condizioni dello stato dell'interfaccia, i possibili problemi associati alle condizioni e le soluzioni per questi problemi.

Condizione riga stato	Possibile problema	Soluzione
Serial x attivo, protocollo di linea attivo		Condizione corretta della riga di stato. Non è richiesta alcuna azione.
Serial x non attivo, protocollo di linea non attivo (modalità DTE)	In genere indica che il router non rileva un segnale CD, ovvero che il CD non è attivo. Problema della compagnia telefonica. La linea non è attiva o non è collegata a CSU/DSU Cablaggio difettoso o non corretto Guasto hardware (CSU/DSU)	Controllare i LED sulla CSU/DSU per verificare se il CD è attivo, oppure inserire una breakout box sulla linea per controllare il segnale del CD. Verificare di utilizzare il cavo e l'interfaccia corretti (consultare la documentazione relativa all'installazione dell'hardware). Inserire una casella di interruzione e controllare tutti i lead di controllo. Contattare la linea in leasing o un altro servizio vettore per verificare la presenza di eventuali problemi. Sostituire i componenti difettosi. Se si sospetta la presenza di hardware del router difettoso, sostituire la linea seriale con un'altra porta. Se la connessione si attiva, l'interfaccia precedentemente connessa presenta un problema.
Serial x attivo, protocollo di linea inattivo (modalità DTE)	Configurazione errata del router locale o remoto I pacchetti keepalive non vengono inviati dal router remoto Linea in leasing o altro servizio di trasporto su linea rumorosa, switch configurato in modo errato o guasto Problema di tempo sul cavo (SCTE non impostato su CSU/DSU) Guasto CSU/DSU locale o remoto CSU/DSU locale o remoto in errore Guasto hardware del router (locale o remoto)	Attivare la modalità di loopback locale per il modem, la CSU o la DSU e utilizzare il comando show interfaces serial per verificare se il protocollo di linea è attivo. Se il protocollo di linea si attiva, è probabile che il problema sia un problema della compagnia telefonica o un router remoto guasto. Se il problema sembra essere sull'estremità remota, ripetere il punto 1 sul modem remoto, CSU o DSU. Verificare tutti i cavi. Verificare che il cavo sia collegato all'interfaccia corretta, che la CSU/DSU sia corretta e che il punto di terminazione di rete della società telefonica sia corretto. Per determinare a quale interfaccia è collegato il cavo, usare il comando show controller EXEC. Abilitare il comando debug serial interface EXEC. Attenzione: poiché all'output di debug viene assegnata una priorità alta nel processo CPU, il sistema potrebbe diventare inutilizzabile. Per questo motivo, usare i comandi di debug solo per risolvere problemi specifici o durante le sessioni di risoluzione dei problemi con il personale del supporto tecnico Cisco. Inoltre, è meglio usare i comandi di debug nei periodi di traffico di rete ridotto e un numero inferiore di utenti. Il debug eseguito in questi periodi riduce la probabilità che un aumento del sovraccarico di elaborazione dei comandi di debug influisca sull'utilizzo del sistema. Se il protocollo di linea non è disponibile in modalità loopback locale e l'output del comando debug serial interface EXEC visualizza che il contatore keepalive non aumenta, è probabile che si sia verificato un problema hardware del router. Sostituire l'hardware dell'interfaccia del router. Se il protocollo di linea viene attivato e il contatore keepalive aumenta, il problema non è il router locale. Risolvere i problemi relativi alla linea seriale come descritto nelle sezioni "Risoluzione dei problemi di clock" e "Test di loopback CSU e DSU" più avanti in questo capitolo. Se si sospetta la presenza di hardware del router difettoso, sostituire la linea seriale con una porta non utilizzata. Se la connessione si attiva, l'interfaccia precedentemente connessa presenta un problema.
Serial x attivo, protocollo di linea inattivo (modalità DCE)	Comando di configurazione dell'interfaccia clockrate mancante Il dispositivo DTE non supporta o non è configurato per la modalità SCTE CSU o DSU remota in errore Cavo guasto o non corretto Errore hardware del router	Aggiungere il comando di configurazione dell'interfaccia clockrate sull'interfaccia seriale. Sintassi: frequenza di clock bps Descrizione sintassi: bps-Frequenza di clock desiderata in bit al secondo: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 50000, 80000, 1000 000, 1300000, 2000000, 4000000 o 8000000. Se possibile, impostare il dispositivo DTE sulla modalità SCTE. Se la CSU/DSU non supporta SCTE, potrebbe essere necessario disabilitare SCTE sull'interfaccia del router Cisco. Vedere la sezione "Inversione dell'orologio di trasmissione" più avanti in questo capitolo. Verificare che venga utilizzato il cavo corretto. Se il protocollo di linea non è attivo, è possibile che si sia verificato un errore hardware o un problema di cablaggio. Inserisci una scatola breakout e osserva i contatti. Se necessario, sostituire le parti difettose.
Serial x attivo, protocollo di linea attivo (a ciclo continuo)	Nel circuito esiste un loop. Il numero di sequenza nel pacchetto keepalive passa a un numero casuale quando viene inizialmente rilevato un loop. Se sullo stesso collegamento viene restituito lo stesso numero casuale, esiste un loop.	Utilizzare il comando show running-config in modalità di esecuzione privilegiata per cercare eventuali voci del comando di configurazione dell'interfaccia di loopback. Se si trova una voce di comando di configurazione dell'interfaccia di loopback, usare il comando di configurazione dell'interfaccia no loopback per rimuovere il loop. Se il comando di configurazione dell'interfaccia loopback non è disponibile, esaminare la CSU/DSU per verificare se è configurata la modalità di loopback manuale. In caso affermativo, disattivare il loopback manuale. Ripristinare la CSU o la DSU e controllare lo stato della linea. Se il protocollo di linea viene attivato, non è necessaria alcuna altra azione. Se la CSU o la DSU non è configurata in modalità loopback manuale, contattare la linea in leasing o un altro servizio vettore per assistenza nella risoluzione dei problemi di linea.
Serial x attivo, protocollo di linea inattivo (disabilitato)	Tasso di errore elevato a causa di un problema del servizio della società telefonica Problema hardware CSU o DSU Hardware del router errato (interfaccia)	Risolvere i problemi relativi alla linea con un analizzatore seriale e breakout box. Cercate di commutare i segnali CTS e DSR. CSU/DSU (loop DTE) a loop. Se il problema persiste, è probabile che si sia verificato un problema hardware. Se il problema persiste, è probabile che ci sia un problema della compagnia telefonica. Sostituire l'hardware danneggiato in base alle esigenze (CSU, DSU, switch, router locale o remoto).
Serial x disattivato a livello amministrativo, protocollo di linea disattivato	La configurazione del router include il comando di configurazione dell'interfaccia shutdown Indirizzo IP duplicato	Controllare la configurazione del router per il comando shutdown. Usare il comando di configurazione dell'interfaccia no shutdown per rimuovere il comando shutdown. Verificare che non vi siano indirizzi IP identici utilizzando il comando show running-config in modalità di esecuzione privilegiata o il comando show interfaces in modalità di esecuzione. Se sono presenti indirizzi duplicati, risolvere il conflitto modificando uno degli indirizzi IP.

Linee seriali: Aumento delle perdite di output sul collegamento seriale

Le perdite di output vengono visualizzate nell'output del comando show interfaces serial (vedere la Figura 15-1) quando il sistema cerca di consegnare un pacchetto a un buffer di trasmissione, ma non sono disponibili buffer.

Sintomo: Un numero crescente di perdite di output sul collegamento seriale.

Tabella 15-2 Linee seriali: Aumento delle perdite di output sul collegamento seriale: questa tabella descrive i possibili problemi che possono causare questo sintomo e suggerisce le soluzioni.

Possibile problema

Soluzione

La velocità di ingresso sull'interfaccia seriale supera la larghezza di banda disponibile sul collegamento seriale

Ridurre al minimo il traffico broadcast periodico (ad esempio il routing e gli aggiornamenti SAP) utilizzando gli elenchi degli accessi o altri metodi. Ad esempio, per aumentare il ritardo tra gli aggiornamenti SAP, usare il comando di configurazione dell'interfaccia ipx sap-interval. Aumentare la dimensione della coda di attesa dell'output con piccoli incrementi (ad esempio, 25%), utilizzando il comando di configurazione dell'interfaccia hold-queue-out. Sulle interfacce interessate, disattivare l'opzione di commutazione veloce per i protocolli più utilizzati. Ad esempio, per disattivare l'opzione di commutazione veloce IP, immettere il comando di configurazione dell'interfaccia no ip route-cache. Per la sintassi dei comandi per altri protocolli, consultare le guide alla configurazione e i riferimenti ai comandi di Cisco IOS. Implementare l'accodamento priorità sui collegamenti seriali più lenti configurando gli elenchi di priorità. Per informazioni sulla configurazione degli elenchi di priorità, consultare le guide alla configurazione e i riferimenti ai comandi di Cisco IOS. Nota: le riduzioni di output sono accettabili in determinate condizioni. Ad esempio, se si sa che un link è sovrautilizzato (e non c'è modo di rimediare alla situazione), spesso è preferibile scartare i pacchetti piuttosto che tenerli in mano. Ciò è vero per i protocolli che supportano il controllo del flusso e possono ritrasmettere i dati (ad esempio TCP/IP e Novell IPX). Tuttavia, alcuni protocolli, come DECnet e local-area transport sono sensibili ai pacchetti scartati e non riescono, se non a ritrasmetterli.

Linee seriali: Aumento delle perdite di input sul collegamento seriale

Le perdite di input vengono visualizzate nell'output del comando show interfaces serial EXEC (vedere la Figura 15-1) quando nel sistema sono ancora in elaborazione troppi pacchetti provenienti da quell'interfaccia.

Sintomo: Numero crescente di cadute di input sul collegamento seriale.

Tabella 15-3: Linee seriali: Aumento delle cadute di input sul collegamento seriale: questa tabella descrive i possibili problemi che possono causare questo sintomo e suggerisce le soluzioni.

Possibile problema

Soluzione

La velocità di input supera la capacità del router o le code di input superano le dimensioni delle code di output

Nota: i problemi di perdita di input si verificano in genere quando il traffico viene instradato tra interfacce più veloci (ad esempio Ethernet, Token Ring e FDDI) e interfacce seriali. Quando il traffico è leggero, non vi sono problemi. Con l'aumento del traffico, i backup iniziano a verificarsi. I router scaricano i pacchetti durante questi periodi di congestione. Aumentare le dimensioni della coda di output sulle interfacce di destinazione comuni per l'interfaccia che sta eliminando i pacchetti. Usare il comando di configurazione dell'interfaccia hold-queue-out. Aumentare queste code di piccoli incrementi (ad esempio, del 25%) fino a quando non vengono più visualizzati cali nell'output show interfaces. Il limite predefinito della coda di attesa dell'output è 100 pacchetti. Ridurre le dimensioni della coda di input, utilizzando il comando hold-queue nella configurazione interfaccia, per forzare le perdite di input a trasformarle in perdite di output. Le perdite di output hanno un impatto minore sulle prestazioni del router rispetto alle perdite di input. La coda di attesa di input predefinita è 75 pacchetti.

Linee seriali: Aumento degli errori di input superiori all'1% del traffico di interfaccia totale

Se nell'output seriale show interfaces vengono visualizzati errori di input (vedere la Figura 15-1), è possibile che l'errore sia stato causato da diverse cause. Le fonti più probabili sono riassunte nella tabella 15-4.

Nota: qualsiasi valore di errore di input per errori CRC (Cyclic Redundancy Check), errori di framing o interruzioni superiori all'1% del traffico di interfaccia totale indica un tipo di problema del collegamento che deve essere isolato e corretto.

Sintomo: Numero crescente di errori di input superiore all'1% del traffico di interfaccia totale.

Tabella 15-4: Linee seriali: Aumento degli errori di input superiori all'1% del traffico di interfaccia totale

Possibile problema

Soluzione

I seguenti problemi possono causare questo sintomo: Apparecchiature della compagnia telefonica difettose Linea seriale rumorosa Configurazione della temporizzazione non corretta (SCTE non impostato) Cavo o cavo non corretto troppo lungo Cavo o connessione non valida CSU o DSU errato Hardware del router non valido Convertitore di dati o altro dispositivo utilizzato tra router e DSU

Nota: Cisco consiglia di non utilizzare i convertitori di dati quando si collega un router a una rete WAN o seriale. Utilizzare un analizzatore seriale per isolare l'origine degli errori di input. Se si rilevano errori, è probabile che si sia verificato un problema hardware o una mancata corrispondenza dell'orologio in un dispositivo esterno al router. Utilizzare i test loopback e ping per isolare l'origine del problema specifico. Per ulteriori informazioni, vedere le sezioni "Utilizzo del comando trace" e "Test di loopback CSU e DSU" più avanti in questo capitolo. Cercate degli schemi. Ad esempio, se gli errori si verificano a intervalli coerenti, possono essere correlati a una funzione periodica, come l'invio di aggiornamenti di routing.

Linee seriali: Risoluzione degli errori di input della linea seriale

Tabella 15-5: In questa tabella vengono descritti i vari tipi di errori di input visualizzati dal comando show interfaces serial (vedere la Figura 15-1), i possibili problemi che possono aver causato gli errori e le soluzioni a tali problemi.

Tipo errore di input (nome campo)	Possibile problema	Soluzione
Errori CRC (CRC)	Gli errori CRC si verificano quando il calcolo CRC non passa per indicare che i dati sono danneggiati per uno dei motivi seguenti: Linea seriale rumorosa Il cavo seriale è troppo lungo o il cavo dalla CSU/DSU al router non è schermato La modalità SCTE non è abilitata su DSU L'orologio della linea CSU non è configurato correttamente Un problema di densità sul collegamento T1 (specifica di codifica o frame errata)	Assicurarsi che la linea sia sufficientemente pulita da soddisfare i requisiti di trasmissione. Se necessario, schermate il cavo. Accertarsi che il cavo sia della lunghezza consigliata: non più di 15,24 metri o 7,62 metri per il collegamento T1. Verificare che tutti i dispositivi siano configurati correttamente per un orologio di linea comune. Impostare SCTE sul DSU locale e remoto. Se la CSU/DSU non supporta SCTE, vedere la sezione "Inversione dell'orologio di trasmissione" più avanti in questo capitolo. Verificare che la CSU/DSU locale e remota sia configurata per lo stesso schema di framing e codifica utilizzato dalla linea in leasing o da un altro servizio vettore (ad esempio, ESF/B8ZS). Contattare la linea in leasing o un altro servizio di trasporto per richiedere l'esecuzione di test di integrità della linea.
Errori di frame (frame)	Un errore di framing si verifica quando un pacchetto non termina su un limite di byte a 8 bit per uno dei seguenti motivi: Linea seriale rumorosa Cavo non progettato correttamente; cavo seriale troppo lungo; il cavo tra la CSU o la DSU e il router non è schermato la modalità SCTE non è abilitata sul DSU; l'orologio di linea della CSU non è configurato correttamente; uno degli orologi è configurato per la temporizzazione locale Un problema di densità sul collegamento T1 (specifica di codifica o frame errata)	Assicurarsi che la linea sia sufficientemente pulita da soddisfare i requisiti di trasmissione. Se necessario, schermate il cavo. Assicurarsi di utilizzare il cavo corretto. Accertarsi che il cavo sia della lunghezza consigliata: non più di 15,24 metri o 7,62 metri per il collegamento T1. Verificare che tutti i dispositivi siano configurati correttamente per l'utilizzo di un orologio di linea comune. Impostare SCTE sul DSU locale e remoto. Se la CSU/DSU non supporta SCTE, vedere la sezione "Inversione dell'orologio di trasmissione" più avanti in questo capitolo. Verificare che la CSU/DSU locale e remota sia configurata per lo stesso schema di framing e codifica utilizzato dalla linea in leasing o da un altro servizio vettore (ad esempio, ESF/B8ZS). Contattare la linea in leasing o un altro servizio di trasporto per richiedere l'esecuzione di test di integrità della linea.
Trasmissione interrotta (interruzione)	Le interruzioni indicano una sequenza non valida di un bit (più di sette in una fila). Di seguito sono riportati i possibili motivi dell'evento: La modalità SCTE non è abilitata su DSU L'orologio della linea CSU non è configurato correttamente Il cavo seriale è troppo lungo o il cavo tra la CSU o la DSU e il router non è schermato Un problema di densità sul collegamento T1 (specifica di codifica o frame errata) Il pacchetto è stato terminato a causa di una reimpostazione dell'interfaccia o di un errore di framing Problema hardware: circuito danneggiato, CSU/DSU errato o interfaccia di invio errata su router remoto	Verificare che tutti i dispositivi siano configurati correttamente per l'utilizzo di un orologio di linea comune. Impostare SCTE sul DSU locale e remoto. Se la CSU/DSU non supporta SCTE, vedere la sezione "Inversione dell'orologio di trasmissione" più avanti in questo capitolo. Se necessario, schermate il cavo. Accertarsi che il cavo rientri nella lunghezza consigliata: non più di 15,24 metri o 7,62 metri per il collegamento T1. Assicurarsi che tutte le connessioni siano funzionanti. Controllare l'hardware su entrambe le estremità del collegamento. Sostituire l'apparecchiatura difettosa, se necessario. Ridurre la velocità dei dati e verificare se le interruzioni diminuiscono. Utilizzare test di loopback locali e remoti per determinare dove si verificano interruzioni. Vedere la sezione "Test speciali della linea seriale" più avanti in questo capitolo. Contattare la linea in leasing o un altro servizio di trasporto per richiedere l'esecuzione di test di integrità della linea.

Linee seriali: Aumento dei ripristini dell'interfaccia sul collegamento seriale

I ripristini dell'interfaccia visualizzati nell'output del comando show interfaces serial EXEC (vedere la Figura 15-1) sono il risultato di pacchetti keep-alive mancanti.

Sintomo: Un numero crescente di ripristini dell'interfaccia sul collegamento seriale.

Tabella 15-6: In questa tabella vengono descritti i possibili problemi che possono causare il sintomo e vengono suggerite le soluzioni.

Possibile problema

Soluzione

I seguenti problemi possono causare questo sintomo: Congestione sul collegamento (in genere associata a perdite di output) Riga non valida che causa transizioni da CD Possibile problema hardware della CSU, del DSU o dello switch

In caso di reimpostazione dell'interfaccia, esaminare altri campi dell'output del comando show interfaces serial per determinare l'origine del problema. Supponendo che venga registrato un aumento delle reimpostazioni dell'interfaccia, esaminare i seguenti campi: Se l'output del comando show interfaces serial contiene un numero elevato di output, consultare la sezione "Serial Lines: Aumentare le perdite di output sul collegamento seriale," in questo capitolo. Controllare il campo Carrier Transitions (Transizioni portanti) nel display show interfaces serial. Se le transizioni della portante sono elevate durante la registrazione dei ripristini dell'interfaccia, il problema potrebbe essere un collegamento errato o un CSU o DSU errato. Contattare il servizio di linea o vettore e sostituire l'apparecchiatura difettosa, se necessario. Esaminare il campo degli errori di input nella visualizzazione seriale di show interfaces. Se gli errori di input sono elevati mentre le reimpostazioni dell'interfaccia aumentano, il problema è probabilmente un collegamento errato o un CSU/DSU errato. Se necessario, contattare la linea in leasing o un altro vettore e sostituire l'apparecchiatura difettosa.

Linee seriali: Aumento del numero di transizioni vettore sul collegamento seriale

Le transizioni della portante vengono visualizzate nell'output del comando show interfaces serial EXEC ogni volta che si verifica un'interruzione nel segnale della portante (ad esempio, un reset dell'interfaccia all'estremità remota di un collegamento).

Sintomo: Un numero crescente di transizioni vettore contano sul collegamento seriale.

La Tabella 15-7 delinea i possibili problemi che possono causare questo sintomo e suggerisce le soluzioni.

Tabella 15-7: Linee seriali: Aumento del numero di transizioni vettore sul collegamento seriale

Possibile problema	Soluzione
I seguenti problemi possono causare questo sintomo: Interruzioni di linea causate da una sorgente esterna (ad esempio, separazione fisica dei cavi, allarmi T1 rossi o gialli o fulmini in qualche punto della rete) Guasto hardware di switch, DSU o router	Controllare l'hardware su entrambe le estremità del collegamento. Collegare una breakout box o un analizzatore seriale e testare per determinare l'origine dei problemi. Se un analizzatore o una breakout box non sono in grado di identificare problemi esterni, controllare l'hardware del router. Sostituire l'apparecchiatura difettosa, se necessario.

Uso del comando show controllers

Il comando show controller EXEC è un altro importante strumento diagnostico per la risoluzione dei problemi delle linee seriali. La sintassi del comando varia a seconda della piattaforma in uso:

• Per le interfacce seriali sui router Cisco serie 7000, usare il comando show controller bus EXEC.

• Per i prodotti Cisco access, usare il comando show controller in modalità di esecuzione.

• Per i dispositivi AGS, CGS e MGS, usare il comando show controller mci EXEC.

La Figura 15-2 mostra l'output del comando show controller bus EXEC. Questo comando è usato sui router Cisco serie 7000 con scheda Fast Serial Interface Processor (FSIP). Controllare l'output del comando per verificare che il cavo all'unità di servizio del canale/unità di servizio digitale (CSU/DSU) sia collegato all'interfaccia corretta. È inoltre possibile controllare la versione del microcodice per verificare se è aggiornata.

Figura 15-2: Output del comando show controller bus

Sui prodotti di accesso come i server e i router Cisco serie 2000, Cisco 2500, Cisco 3000 e Cisco 4000, usare il comando show controller EXEC. La Figura 15-3 mostra l'output del comando show controller dall'interfaccia BRI (Basic Rate Interface) e dalle interfacce seriali su un server di accesso Cisco 2503. Si noti che alcuni output non vengono visualizzati.

L'output show controller indica lo stato dei canali di interfaccia e se un cavo è collegato all'interfaccia. Nella Figura 15-3, l'interfaccia seriale 0 ha un cavo RS-232 DTE collegato. L'interfaccia seriale 1 non ha cavi collegati.

La Figura 15-4 mostra l'output del comando show controller mci. Questo comando è usato solo sui router AGS, CGS e MGS. Se l'interfaccia elettrica è visualizzata come SCONOSCIUTA (anziché come V.35, EIA/TIA-449 o un altro tipo di interfaccia elettrica), è probabile che il problema sia causato da un cavo non collegato correttamente. È inoltre possibile che la scheda presenti un guasto o un problema nel cablaggio interno. Se l'interfaccia elettrica è sconosciuta, sul display corrispondente al comando show interfaces serial EXEC verrà visualizzato che l'interfaccia e il protocollo di linea sono inattivi.

Figura 15-3: Output comando show controllers

Figura 15-4: Output del comando show controller mci

Uso dei comandi di debug

L'output dei vari comandi debug privileged EXEC fornisce informazioni diagnostiche sullo stato del protocollo e sull'attività di rete per molti eventi di internetworking.

Attenzione:  Poiché all'output di debug viene assegnata una priorità alta nel processo CPU, il sistema potrebbe diventare inutilizzabile. Per questo motivo, usare i comandi di debug solo per risolvere problemi specifici o durante le sessioni di risoluzione dei problemi con il personale del supporto tecnico Cisco. Inoltre, è meglio usare i comandi di debug nei periodi di traffico di rete ridotto e un numero inferiore di utenti. Il debug eseguito in questi periodi riduce la probabilità che un aumento del sovraccarico di elaborazione dei comandi di debug influisca sull'utilizzo del sistema. Dopo aver terminato di usare un comando debug, disabilitarlo con il comando no debug specifico o con il comando no debug all.

I seguenti comandi debug sono utili per risolvere i problemi seriali e WAN. Per ulteriori informazioni sulla funzione e l'output di ciascuno di questi comandi, vedere la pubblicazione di riferimento per i comandi di debug:

• debug serial interface: verifica se i pacchetti keepalive HDLC sono in aumento. In caso contrario, è possibile che esista un problema di temporizzazione sulla scheda di interfaccia o nella rete.

• debug x25 events: rileva gli eventi X.25, ad esempio l'apertura e la chiusura di circuiti virtuali commutati (SVC). Le informazioni relative alla causa e alla diagnostica risultanti sono incluse nel report degli eventi.

• debug lapb: genera informazioni su Link Access Procedure, Balanced (LAPB) o Level 2 X.25.

• debug arp: indica se il router sta inviando informazioni sui router (con pacchetti ARP) o se sta imparando qualcosa su di essi sull'altro lato del cloud WAN. Utilizzare questo comando quando alcuni nodi di una rete TCP/IP rispondono ma altri no.

• debug frame-relay lmi: ottiene le informazioni LMI (Local Management Interface) utili per determinare se uno switch Frame Relay e un router stanno inviando e ricevendo pacchetti LMI.

• debug frame-relay events: determina se si verificano scambi tra un router e uno switch Frame Relay.

• debug ppp negotiation: visualizza i pacchetti PPP (Point-to-Point Protocol) trasmessi durante l'avvio del protocollo PPP, in cui le opzioni PPP vengono negoziate.

• debug ppp packet: visualizza i pacchetti PPP inviati e ricevuti. Con questo comando vengono visualizzati i dump di pacchetti di basso livello.

• debug ppp errors: visualizza gli errori PPP (ad esempio frame non validi o in formato non corretto) associati alla negoziazione e al funzionamento della connessione PPP.

• debug ppp chap: visualizza gli scambi di pacchetti CHAP (Challenge Handshake Authentication Protocol) e PAP (Password Authentication Protocol) di PPP.

• debug serial packet: visualizza i pacchetti Switched Multimegabit Data Service (SMDS) in fase di invio e ricezione. Questo display visualizza anche messaggi di errore che indicano il motivo per cui un pacchetto non è stato inviato o è stato ricevuto per errore. Per SMDS, il comando esegue il dump dell'intera intestazione SMDS e di alcuni dati di payload quando un pacchetto SMDS viene trasmesso o ricevuto.

Uso dei test ping estesi

Il comando ping è un test utile disponibile sui dispositivi di internetworking Cisco e su molti sistemi host. In TCP/IP, questo strumento diagnostico è noto anche come richiesta echo ICMP (Internet Control Message Protocol).

Nota: il comando ping è particolarmente utile quando si registrano alti livelli di errori di input nella visualizzazione seriale di show interfaces. Vedere la Figura 15-1.

I dispositivi di internetworking Cisco offrono un meccanismo per automatizzare l'invio di molti pacchetti ping in sequenza. La Figura 15-5 illustra il menu utilizzato per specificare le opzioni ping estese. In questo esempio vengono specificati 20 ping successivi. Tuttavia, quando si esegue il test dei componenti sulla linea seriale, è necessario specificare un numero molto più grande, ad esempio 1000 ping.

Figura 15-5: Menu esteso delle specifiche ping

Esecuzione dei test Ping

In generale, eseguire i test ping della linea seriale come segue:

1. Attivare la modalità di loopback locale per CSU o DSU.

2. Configurare il comando ping esteso per inviare modelli di dati e dimensioni di pacchetto diversi. Le figure 15-6 e 15-7 illustrano due utili test ping, un ping tutto zero (1500 byte) e un ping tutto uno (1500 byte).

3. Esaminare l'output del comando show interfaces serial (vedere la Figura 15-1) e determinare se gli errori di input sono aumentati. Se gli errori di input non sono aumentati, probabilmente l'hardware locale (DSU, cavo, scheda di interfaccia router) è in buone condizioni.

   Supponendo che questa sequenza di test sia stata richiesta dalla presenza di un numero elevato di errori CRC e di framing, è probabile che si sia verificato un problema di clock. Controllare se la CSU o la DSU presenta un problema di temporizzazione. Vedere la sezione "Risoluzione dei problemi di clock" più avanti in questo capitolo.

4. Se la configurazione della temporizzazione è corretta e funziona correttamente, attivare la modalità di loopback remoto per l'unità CSU o DSU.

5. Ripetere il test ping e cercare le modifiche nelle statistiche degli errori di input.

6. Se gli errori di input aumentano, è presente un problema nella linea seriale o nella CSU/DSU. Contattare il provider di servizi WAN e sostituire la CSU o la DSU. Se il problema persiste, contattare il supporto tecnico.

Figura 15-6: Test ping AL-Zeros da 1500 byte

Figura 15-7: test ping All-One da 1500 byte

Risoluzione dei problemi di clock

I conflitti di clock nelle connessioni seriali possono causare la perdita cronica del servizio di connessione o una riduzione delle prestazioni. In questa sezione vengono illustrati gli aspetti importanti dei problemi di clock: cause dei problemi di clock, rilevamento dei problemi di clock, isolamento dei problemi di clock e soluzioni dei problemi di clock.

Panoramica della temporizzazione

La CSU/DSU deriva l'orologio dati dai dati che vi passano attraverso. Per ripristinare l'orologio, l'hardware CSU/DSU deve ricevere almeno un valore a 1 bit ogni 8 bit di dati che lo attraversano; questa è nota come densità one. Il mantenimento della densità consente all'hardware di ripristinare il clock dei dati in modo affidabile.

Nelle implementazioni T1 più recenti viene comunemente utilizzato il framing Extended Superframe Format (ESF) con la codifica binaria B8ZS. B8ZS fornisce uno schema in base al quale un codice speciale viene sostituito ogni volta che otto zeri consecutivi vengono inviati tramite il collegamento seriale. Questo codice viene quindi interpretato all'estremità remota della connessione. Questa tecnica garantisce una densità indipendente dal flusso di dati.

Le precedenti implementazioni di T1 utilizzano il formato D4, noto anche come frame Superframe Format (SF) e codifica AMI (Alternate Mark Inversion). L'AMI non utilizza uno schema di codifica come B8ZS. In questo modo viene limitato il tipo di dati che è possibile trasmettere perché la densità dei dati non viene mantenuta indipendentemente dal flusso di dati.

Un altro elemento importante nelle comunicazioni seriali è la sincronizzazione dei terminali SCTE (Serial Clock Transmit External). SCTE è l'orologio richiamato dal dispositivo DTE (Data Terminal Equipment) (ad esempio, un router) al dispositivo DCE (Data Communications Equipment) (ad esempio, il CSU/DSU).

Quando il dispositivo DCE utilizza SCTE invece dell'orologio interno per campionare i dati dal DTE, è preferibile campionare i dati senza errori anche in caso di spostamento di fase del cavo tra il CSU/DSU e il router. Si consiglia di utilizzare SCTE per trasmissioni seriali più veloci di 64 kbps. Se la CSU/DSU non supporta SCTE, vedere la sezione "Inversione dell'orologio di trasmissione" più avanti in questo capitolo.

Cause dei problemi di clock

In generale, i problemi di clock nelle interconnessioni WAN seriali possono essere attribuiti a una delle seguenti cause:

• Configurazione DSU non corretta

• Configurazione CSU non corretta

• Cavi non conformi alle specifiche, ovvero più lunghi di 15,24 metri o non schermati

• Connessioni del pannello patch rumorose o scarse

• Diversi cavi collegati in fila

Rilevamento dei problemi di clock

Per rilevare i conflitti di clock su un'interfaccia seriale, cercare gli errori di input come segue:

1. Usare il comando show interfaces serial EXEC sui router a entrambe le estremità del collegamento.

2. Esaminare l'output del comando per individuare CRC, errori di framing e interruzioni.

3. Se uno di questi passaggi indica errori che superano un intervallo approssimativo dello 0,5% o del 2,0% del traffico sull'interfaccia, è probabile che esistano problemi di clock in qualche punto della WAN.

4. Isolare l'origine dei conflitti di clock come descritto nella sezione seguente, "Isolamento dei problemi di clock".

5. Ignorare o riparare eventuali pannelli di patch difettosi.

Isolamento dei problemi di clock

Dopo aver determinato che i conflitti di clock sono la causa più probabile degli errori di input, la procedura seguente consente di isolare l'origine di tali errori:

1. Eseguire una serie di test ping e di test di loopback (sia in locale che in remoto), come descritto nella sezione "Test di loopback CSU e DSU" più indietro in questo capitolo.

2. Determinare la fine della connessione che è all'origine del problema o se il problema è nella linea. Nella modalità loopback locale, eseguire diversi modelli e dimensioni nei test ping (ad esempio, usare datagrammi da 1500 byte). L'utilizzo di un modello e di dimensioni di pacchetto singoli potrebbe non forzare il verificarsi di errori, in particolare quando il problema è un cavo seriale al router o CSU/DSU.

3. Usare il comando show interfaces serial EXEC per determinare se i conteggi degli errori di input aumentano e dove si accumulano.

Se si verificano errori di input su entrambe le estremità della connessione, il problema più probabile è la temporizzazione della CSU.

Se si verificano errori di input in una sola estremità, è probabile che si sia verificato un problema di clocking o cablaggio DSU.

L'opzione Interrompi da un lato indica che dall'altro lato vengono inviate informazioni non valide o che esiste un problema di linea.

Nota: fare sempre riferimento all'output del comando show interfaces serial (vedere la Figura 15-1) e registrare le modifiche nel numero di errori o notare se il numero di errori non cambia.

Soluzioni ai problemi di clock

Tabella 15-8 Linee seriali: Problemi di clock e soluzioni: In questa tabella vengono descritti i rimedi consigliati per i problemi di clock, in base all'origine del problema.

Possibile problema	Soluzione
Configurazione CSU non corretta	Determinare se i CSU su entrambe le estremità concordano sull'origine dell'orologio (locale o di linea). Se le CSU non sono in accordo, configurarle in modo che lo facciano. In genere la linea è l'origine. Controllare l'impostazione LBO sulla CSU per verificare che l'impedenza corrisponda a quella della linea fisica. Per informazioni sulla configurazione della CSU, consultare la documentazione dell'hardware della CSU.
Configurazione DSU non corretta	Determinare se la modalità SCTE è attivata per le DSU su entrambe le estremità. Se SCTE non è abilitato su entrambe le estremità della connessione, abilitarlo. Assicuratevi che la densità dei dischi sia mantenuta. Ciò richiede che l'unità di distribuzione utilizzi gli stessi schemi di framing e codifica (ad esempio, ESF e B8ZS) utilizzati dalla linea affittata o da un altro servizio vettore. Per informazioni sugli schemi di framing e codifica, contattare il provider della linea in leasing. Se il servizio di trasporto utilizza la codifica AMI, invertire l'orologio di trasmissione su entrambi i lati del collegamento oppure eseguire l'unità DSU in modalità bit-roba. Per informazioni sulla configurazione della DSU, consultare la documentazione dell'hardware della DSU.
Il cavo per il router non è conforme alle specifiche	Se il cavo è più lungo di 15,24 metri, utilizzare un cavo più corto. Se il cavo non è schermato, sostituirlo con un cavo schermato.

Inversione dell'orologio di trasmissione

Se si stanno tentando connessioni seriali a velocità superiori a 64 kbps con una CSU/DSU che non supporta SCTE, potrebbe essere necessario invertire l'orologio di trasmissione sul router. L'inversione dell'orologio di trasmissione compensa gli spostamenti di fase tra i segnali di dati e dell'orologio.

Il comando specifico usato per invertire l'orologio di trasmissione varia a seconda della piattaforma in uso. Su un router Cisco serie 7000, immettere il comando di configurazione dell'interfaccia inversa-clock. Per i router Cisco serie 4000, usare il comando di configurazione dell'interfaccia dte-invert-txc.

Per assicurarsi di utilizzare la sintassi dei comandi corretta per il router, consultare il manuale dell'utente del router o del server di accesso e i manuali di configurazione e i riferimenti ai comandi di Cisco IOS.

Nota: sulle piattaforme meno recenti, per invertire l'orologio di trasmissione potrebbe essere necessario spostare un ponticello fisico.

Adeguamento dei buffer

L'utilizzo eccessivo della larghezza di banda (oltre il 70%) determina una riduzione delle prestazioni complessive e può causare guasti intermittenti. Ad esempio, la trasmissione di file DECnet potrebbe non riuscire a causa di pacchetti scartati da qualche parte nella rete.

Se la situazione è già abbastanza grave, devi aumentare la larghezza di banda del collegamento. Tuttavia, l'aumento della larghezza di banda potrebbe non essere necessario o immediatamente pratico. Per risolvere i problemi di sovrautilizzo della linea seriale marginale, è possibile controllare il modo in cui il router utilizza i buffer di dati.

Attenzione: in generale, non regolare i buffer di sistema a meno che non si stia lavorando a stretto contatto con un rappresentante del supporto tecnico Cisco. Se si regolano in modo errato i buffer di sistema sul router, è possibile compromettere gravemente le prestazioni dell'hardware e della rete.

Utilizzare una delle tre opzioni seguenti per controllare la modalità di utilizzo dei buffer:

• Regolare i parametri associati ai buffer di sistema

• Specificare il numero di pacchetti contenuti nelle code di input o output (code di attesa)

• Assegnazione di priorità alla modalità di accodamento del traffico per la trasmissione (priority output queuing)

I comandi di configurazione associati a queste opzioni sono descritti nelle guide alla configurazione e nei riferimenti ai comandi di Cisco IOS.

La sezione seguente è incentrata sull'identificazione delle situazioni in cui è probabile che queste opzioni vengano applicate e sulla definizione di come utilizzare queste opzioni per risolvere i problemi di connettività e prestazioni nelle interconnessioni seriali/WAN.

Ottimizzazione dei buffer di sistema

I router Cisco dispongono di due tipi di buffer generali: buffer hardware e buffer di sistema. Solo i buffer di sistema sono configurabili direttamente dagli amministratori di sistema. I buffer hardware vengono utilizzati specificamente come buffer di ricezione e trasmissione associati a ciascuna interfaccia e (in assenza di una configurazione speciale) vengono gestiti dinamicamente dal software di sistema stesso.

I buffer di sistema sono associati alla memoria di sistema principale e sono allocati a blocchi di memoria di dimensioni diverse. Un comando utile per determinare lo stato dei buffer di sistema è il comando show buffer EXEC. La Figura 15-8 mostra l'output del comando show buffers.

Figura 15-8: output del comando show buffers

Nell'output show buffers:

• totale: identifica il numero totale di buffer nel pool, inclusi i buffer utilizzati e non utilizzati.

• permanent: identifica il numero permanente di buffer allocati nel pool. Questi buffer sono sempre nel pool e non possono essere eliminati.

• nell'elenco di disponibilità: identifica il numero di buffer attualmente presenti nel pool che possono essere utilizzati.

• min: identifica il numero minimo di buffer che il processore di routing (RP) deve cercare di mantenere nell'elenco di disponibilità:

  • Il parametro min viene utilizzato per prevedere la domanda di buffer dal pool in un determinato momento.

  • Se il numero di buffer nell'elenco di disponibilità è inferiore al valore minimo, l'RP tenta di creare più buffer per quel pool.

• max allowed: identifica il numero massimo di buffer consentiti nell'elenco di disponibilità:

  • Il parametro max allowed impedisce a un pool di monopolizzare i buffer non più necessari e libera nuovamente la memoria nel sistema per un ulteriore utilizzo.

  • Se il numero di buffer nell'elenco di disponibilità è maggiore del valore massimo consentito, l'RP deve tentare di tagliare i buffer dal pool.

• accessi riusciti: identifica il numero di buffer richiesti dal pool. Il contatore visite consente di determinare il pool che deve soddisfare la richiesta più elevata di buffer.

• mancati riscontri: identifica il numero di volte in cui un buffer è stato richiesto e il server di replica ha rilevato la necessità di buffer aggiuntivi. In altre parole, il numero di buffer nell'elenco di disponibilità è sceso al di sotto del valore minimo. Il contatore dei mancati riscontri rappresenta il numero di volte in cui l'RP è stato costretto a creare ulteriori buffer.

• trims: identifica il numero di buffer eliminati dal pool dal server di archiviazione quando il numero di buffer nell'elenco di disponibilità supera il numero massimo consentito.

• creato: identifica il numero di buffer creati nel pool. L'RP crea i buffer quando la richiesta di buffer è aumentata fino a quando il numero di buffer nell'elenco di disponibilità non è inferiore al numero minimo di buffer e/o si verifica un mancato accesso a causa di zero buffer nell'elenco di disponibilità.

• errori: identifica il numero di errori di concessione di un buffer a un richiedente anche dopo aver tentato di creare un buffer aggiuntivo. Il numero di errori rappresenta il numero di pacchetti scartati a causa di una carenza di buffer.

• no memory: identifica il numero di errori causati da memoria insufficiente per creare buffer aggiuntivi.

L'output del comando show buffers nella Figura 15-8 indica numeri alti nei tagli e crea campi per i buffer di grandi dimensioni. Se si ricevono numeri elevati in questi campi, è possibile aumentare le prestazioni del collegamento seriale aumentando il valore libero massimo configurato per i buffer di sistema. trims identifica il numero di buffer rimossi dal pool dall'RP quando il numero di buffer nell'elenco di disponibilità supera il numero di buffer massimo consentito.

Utilizzare il comando di configurazione globale buffer max free number per aumentare il numero di buffer di sistema liberi. Il valore configurato deve corrispondere approssimativamente al 150% della cifra indicata nel campo totale dell'output del comando show buffers. Ripetere questo processo finché l'output show buffers non indica più i tagli e i buffer creati.

Se l'output del comando show buffers mostra un numero elevato di errori nel campo (nessuna memoria) (vedere l'ultima riga di output nella Figura 15-8), è necessario ridurre l'uso dei buffer di sistema o aumentare la quantità di memoria condivisa o principale (RAM fisica) sul router. Per assistenza, contattare il supporto tecnico.

Implementazione dei limiti delle code di attesa

Le code di attesa sono buffer utilizzati da ogni interfaccia del router per archiviare pacchetti in entrata o in uscita. Usare il comando di configurazione dell'interfaccia hold-queue per aumentare il numero di pacchetti di dati in coda prima che il router scarti i pacchetti. Aumentare queste code di piccoli incrementi (ad esempio, del 25%) fino a quando non vengono più visualizzati cali nell'output show interfaces. Il limite predefinito della coda di attesa dell'output è 100 pacchetti.

Nota: il comando hold-queue viene utilizzato per i pacchetti con commutazione di contesto e gli aggiornamenti periodici generati dal router.

Utilizzare il comando hold-queue per impedire che i pacchetti vengano scartati e per migliorare le prestazioni del collegamento seriale nelle seguenti condizioni:

• Si dispone di un'applicazione che non può tollerare interruzioni e il protocollo è in grado di tollerare ritardi più lunghi. DECnet è un esempio di protocollo che soddisfa entrambi i criteri. Il Local-Area Transport (LAT) non lo fa perché non tollera ritardi.

• L'interfaccia è molto lenta. L'utilizzo della larghezza di banda è basso o l'utilizzo previsto potrebbe superare sporadicamente la larghezza di banda disponibile.

Nota: quando si aumenta il numero specificato per una coda di blocco dell'output, potrebbe essere necessario aumentare il numero di buffer di sistema. Il valore utilizzato dipende dalle dimensioni dei pacchetti associati al traffico previsto per la rete.

Utilizzo di Priority Queuing per ridurre i colli di bottiglia

L'accodamento delle priorità è un meccanismo di controllo basato su un elenco che consente di assegnare una priorità al traffico a seconda dell'interfaccia. L'accodamento delle priorità prevede due passaggi:

1. Creare un elenco di priorità per tipo di protocollo e livello di priorità.

2. Assegnare l'elenco di priorità a un'interfaccia specifica.

Entrambe queste procedure utilizzano versioni del comando di configurazione globale priority-list. Inoltre, è possibile applicare un ulteriore controllo del traffico facendo riferimento ai comandi di configurazione globale access-list delle specifiche priority-list. Per esempi sulla definizione degli elenchi di priorità e per dettagli sulla sintassi dei comandi associata all'accodamento delle priorità, consultare le guide alla configurazione e i riferimenti ai comandi di Cisco IOS.

Nota: Accodamento priorità crea automaticamente quattro code di attesa di dimensioni variabili. In questo modo si ignora qualsiasi specifica della coda di attesa inclusa nella configurazione.

Utilizzare l'accodamento delle priorità per impedire che i pacchetti vengano scartati e per migliorare le prestazioni dei collegamenti seriali nelle seguenti condizioni:

• Quando l'interfaccia è lenta, vengono trasmessi diversi tipi di traffico e si desidera migliorare le prestazioni del traffico terminale.

• Se un collegamento seriale presenta carichi molto pesanti (ad esempio, trasferimenti di file in momenti specifici), l'accodamento delle priorità consentirà di selezionare i tipi di traffico da scartare in periodi di traffico elevato.

In generale, iniziare con il numero predefinito di code durante l'implementazione delle code di priorità. Dopo aver abilitato l'accodamento di priorità, l'output del monitor viene interrotto con il comando show interfaces serial EXEC. Se si notano perdite di output nella coda del traffico per cui è stata specificata la priorità alta, aumentare il numero di pacchetti che possono essere accodati utilizzando l'opzione della parola chiave queue-limit del comando di configurazione globale priority-list. Gli argomenti del limite di coda predefiniti sono 20 pacchetti per la coda ad alta priorità, 40 per media, 60 per normale e 80 per bassa.

Nota: quando si crea un ponte tra il traffico LAT di Digital Equipment Corporation (DEC), il router deve rilasciare un numero molto ridotto di pacchetti o le sessioni LAT possono terminare in modo imprevisto. Una profondità di coda ad alta priorità pari a circa 100 (specificata con la parola chiave queue-limit) è un tipico valore di lavoro quando il router scarta i pacchetti di output e le linee seriali sono soggette a un utilizzo della larghezza di banda pari a circa il 50%. Se il router scarta i pacchetti e ha raggiunto il 100% di utilizzo, è necessaria un'altra linea.

Un altro strumento per alleviare la congestione quando si collega DEC LAT è la compressione LAT. Per implementare la compressione LAT, usare il comando di configurazione interfaccia bridge-group group lat-compression.

Test speciali della linea seriale

Oltre alle funzionalità diagnostiche di base disponibili sui router, è possibile utilizzare una varietà di strumenti e tecniche supplementari per determinare le condizioni di cavi, apparecchiature di commutazione, modem, host e hardware per l'internetworking remoto. Per ulteriori informazioni, consultare la documentazione della CSU, del DSU, dell'analizzatore seriale o di altre apparecchiature.

Test di loopback CSU e DSU

Se l'output del comando show interfaces serial EXEC indica che la linea seriale è attiva ma il protocollo della linea non è attivo, usare i test di loopback CSU/DSU per determinare la causa del problema. Eseguire prima il test del loop locale, quindi il test remoto. La Figura 15-9 illustra la topologia di base dei test di loopback locale e remoto CSU/DSU.

Figura 15-9: Test di loopback locale e remoto CSU/DSU

Nota: questi test sono di natura generica e presuppongono il collegamento del sistema di internetworking a una CSU o a una DSU. Tuttavia, i test sono essenzialmente gli stessi per il collegamento a un multiplexer con funzionalità CSU/DSU incorporate. Poiché non esiste il concetto di loopback in ambienti PSN (Packet-Switched Network) X.25 o Frame Relay, i test di loopback non sono applicabili alle reti X.25 e Frame Relay.

Test di loopback locale CSU e DSU per collegamenti HDLC o PPP

Di seguito è riportata una procedura generale per eseguire i test di loopback insieme alle funzionalità di diagnostica di sistema incorporate:

1. Posizionare CSU/DSU in modalità di loop locale (consultare la documentazione del fornitore). Nella modalità di loop locale, l'uso dell'orologio di linea (dal servizio T1) viene interrotto e l'unità DSU è costretta a utilizzare l'orologio locale.

2. Utilizzare il comando show interfaces serial EXEC per determinare se lo stato della linea cambia da "line protocol is down" a "line protocol is up (looped)" o se rimane inattivo.

3. Se il protocollo di linea viene attivato quando la CSU o la DSU è in modalità loopback locale, il problema si verifica sull'estremità remota della connessione seriale. Se lo stato della linea di stato non cambia, è possibile che il router, il cavo di connessione o CSU/DSU contenga un problema.

4. Se il problema è locale, usare il comando debug serial interface in modalità di esecuzione privilegiata.

5. Uscire dalla modalità di loop locale. Quando il protocollo di linea non è attivo, l'output del comando debug serial interface indicherà che i contatori keepalive non sono in aumento.

6. Posizionare nuovamente la CSU/DSU in modalità di loop locale. In questo modo, i pacchetti keepalive dovrebbero iniziare a crescere. In particolare, i valori per mineseen e yourseen keepalives aumenteranno ogni 10 secondi. Queste informazioni verranno visualizzate nell'output dell'interfaccia seriale di debug.

   Se i pacchetti keepalive non si incrementano, potrebbe essersi verificato un problema di temporizzazione sulla scheda di interfaccia o sulla rete. Per informazioni sulla correzione dei problemi di temporizzazione, vedere la sezione "Risoluzione dei problemi di temporizzazione" più indietro in questo capitolo.

   Se i pacchetti keepalive non si incrementano, potrebbe essersi verificato un problema di temporizzazione sulla scheda di interfaccia o sulla rete. Per informazioni sulla correzione dei problemi di temporizzazione, vedere la sezione "Risoluzione dei problemi di temporizzazione" più indietro in questo capitolo.

7. Controllare il router locale, l'hardware CSU/DSU e gli eventuali cavi collegati. Accertarsi che i cavi siano della lunghezza consigliata non superiore a 15,24 metri (50 ft) o 7,62 metri (25 ft) per un collegamento T1. Accertarsi che i cavi siano collegati alle porte corrette. Sostituire l'apparecchiatura difettosa, se necessario.

La Figura 15-10 mostra l'output del comando debug serial interface per una connessione seriale HDLC, in cui i pacchetti keepalive non sono riusciti a interrompere la linea e a reimpostare l'interfaccia.

Figura 15-10: Output del comando debug serial interface

Test di loopback remoto CSU e DSU per collegamenti HDLC o PPP

Se si determina che l'hardware locale funziona correttamente ma si verificano ancora problemi durante il tentativo di stabilire connessioni tramite il collegamento seriale, provare a utilizzare il test di loopback remoto per isolare la causa del problema.

Nota: questo test di loopback remoto presuppone che sia in uso l'incapsulamento HDLC e che il precedente test del loop locale sia stato eseguito immediatamente prima di questo test.

Per eseguire il test di loopback, è necessario eseguire i passi riportati di seguito.

1. Attivare la modalità di loopback remoto della CSU o della DSU remota (consultare la documentazione del fornitore).

2. Utilizzando il comando show interfaces serial EXEC, determinare se il protocollo di linea rimane attivo con la riga di stato indicante "Serial x is up, line protocol is up (looped)", o se scende con la riga di stato indicante "line protocol is down".

3. Se il protocollo di linea rimane attivo (loop), il problema è probabilmente causato dall'estremità remota della connessione seriale (tra il CSU/DSU remoto e il router remoto). Eseguire test locali e remoti sull'estremità remota per isolare l'origine del problema.

4. Se lo stato della linea cambia in "protocollo di linea inattivo" quando la modalità di loopback remoto è attivata, verificare che la densità sia mantenuta correttamente. La CSU/DSU deve essere configurata in modo da utilizzare gli stessi schemi di framing e codifica utilizzati dalla linea in leasing o da altri servizi di trasporto (ad esempio, ESF e B8ZS).

5. Se i problemi persistono, contattare il gestore della rete WAN o l'organizzazione del servizio WAN.

Informazioni dettagliate sul comando seriale show interfaces

Le sottosezioni seguenti descrivono i parametri del comando show interfaces serial , la descrizione della sintassi, la visualizzazione dell'output di esempio e le descrizioni dei campi.

show interfaces serial Parameters

Per visualizzare informazioni su un'interfaccia seriale, utilizzare il comando show interfaces serial privileged EXEC:

show interfaces serial [number] [accounting]
show interfaces serial [number [:channel-group] [accounting] (Cisco 4000 series)
show interfaces serial [slot | port [:channel-group]] [accounting] (Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [serial] 
(ports on VIP cards in the Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [:t1-channel] [accounting | crb]
(CT3IP in Cisco 7500 series)

Descrizione della sintassi

• number - Facoltativo. Numero di porta.

• accounting-Facoltativo. Visualizza il numero di pacchetti di ciascun tipo di protocollo inviati tramite l'interfaccia.

• :channel-group -Facoltativo. Su Cisco serie 4000 con NPM o Cisco serie 7500 con MIP, specifica il numero di gruppo di canali T1 nell'intervallo da 0 a 23, definito con il comando di configurazione del controller del gruppo di canali.

• slot: per informazioni sugli slot, consultare il manuale dell'hardware appropriato.

• porta: per informazioni sulla porta, consultare il manuale dell'hardware appropriato.

• port-adapter: per informazioni sulla compatibilità dell'adattatore di porta, fare riferimento al manuale dell'hardware appropriato.

• :t1-channel-Facoltativo. Per il CT3IP, il canale T1 è un numero compreso tra 1 e 28.

• I canali T1 sul CT3IP sono numerati da 1 a 28 invece che con il più tradizionale schema a base zero (da 0 a 27) usato con altri prodotti Cisco. In questo modo si garantisce la coerenza con gli schemi di numerazione Telco per i canali T1 nelle apparecchiature T3 canalizzate.

• crb-Facoltativo. Mostra informazioni di bridging e routing dell'interfaccia.

Modalità comando

EXEC privilegiati

Linee guida per l'utilizzo

Questo comando è apparso per la prima volta in Cisco IOS versione 10.0 per la serie Cisco 4000. È apparso per la prima volta in Cisco IOS versione 11.0 per la serie 7000, ed è stato modificato in Cisco IOS versione 11.3 per includere il CT3IP.

Display di esempio

Di seguito viene riportato un esempio di output del comando show interfaces per un'interfaccia seriale sincrona:

Router# show interfaces serial
Serial 0 is up, line protocol is up
   Hardware is MCI Serial
   Internet address is 150.136.190.203, subnet mask is 255.255.255.0
   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation HDLC, loopback not set, keepalive set (10 sec)
   Last input 0:00:07, output 0:00:00, output hang never
   Output queue 0/40, 0 drops; input queue 0/75, 0 drops
   Five minute input rate 0 bits/sec, 0 packets/sec
   Five minute output rate 0 bits/sec, 0 packets/sec
       16263 packets input, 1347238 bytes, 0 no buffer
       Received 13983 broadcasts, 0 runts, 0 giants
       2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
1 carrier transitions 
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts

Descrizione campo

Tabella 15-9: show interfaces serial Field Descriptions: questa tabella descrive i campi significativi visualizzati nell'output.

Campo	Descrizione
Seriale...è {up | inattivo}...disattivato a livello amministrativo	Indica se l'hardware dell'interfaccia è attualmente attivo (rilevamento vettore è presente) o se è stato disattivato da un amministratore.
protocollo di linea {up} | giù}	Indica se i processi software che gestiscono il protocollo di linea considerano la linea utilizzabile (ovvero, se i pacchetti keepalive hanno esito positivo) o se è stata disattivata da un amministratore.
protocollo di linea {up} | giù}	Indica se i processi software che gestiscono il protocollo di linea considerano la linea utilizzabile (ovvero, se i pacchetti keepalive hanno esito positivo) o se è stata disattivata da un amministratore.
L'hardware è	Specifica il tipo di hardware.
L'indirizzo Internet è	Specifica l'indirizzo Internet e la subnet mask.
MTU	Unità massima di trasmissione dell'interfaccia.
BW	Indica il valore del parametro della larghezza di banda configurato per l'interfaccia (in kilobit al secondo). Il parametro della larghezza di banda viene utilizzato solo per calcolare le metriche IGRP. Se l'interfaccia è collegata a una linea seriale con una velocità di linea non corrispondente a quella predefinita (1536 o 1544 per T1 e 56 per una linea seriale sincrona standard), utilizzare il comando bandwidth per specificare la velocità di linea corretta per questa linea seriale.
GIORNO	Ritardo dell'interfaccia in microsecondi.
affidarsi	Affidabilità dell'interfaccia come frazione di 255 (255/255 è un'affidabilità al 100%), calcolata come media esponenziale su cinque minuti.
caricare	Affidabilità dell'interfaccia come frazione di 255 (255/255 è un'affidabilità al 100%), calcolata come media esponenziale su cinque minuti.
Incapsulamento	Metodo di incapsulamento assegnato all'interfaccia.
loopback	Indica se è impostato il loopback.
keepalive	Indica se i pacchetti keepalive sono impostati.
Ultimo input	Numero di ore, minuti e secondi trascorsi dalla ricezione corretta dell'ultimo pacchetto da parte di un'interfaccia. Utile per sapere quando un'interfaccia inattiva è guasta.
Ultimo output	Numero di ore, minuti e secondi trascorsi dall'ultimo pacchetto trasmesso correttamente da un'interfaccia. Numero di ore, minuti e secondi trascorsi dall'ultimo pacchetto trasmesso correttamente da un'interfaccia.
interruzione dell'output	Numero di ore, minuti e secondi (o mai) dall'ultima reimpostazione dell'interfaccia a causa di una trasmissione che ha richiesto troppo tempo. Quando il numero di ore in uno degli ultimi campi supera 24, viene stampato il numero di giorni e di ore. Se il campo è in eccesso, vengono stampati degli asterischi.
Coda di output, elimina la coda di input, elimina	Numero di pacchetti nelle code di output e di input. Ogni numero è seguito da una barra, dalle dimensioni massime della coda e dal numero di pacchetti perché la coda è piena.
Velocità di ingresso di 5 minuti Velocità di uscita di 5 minuti	Numero medio di bit e pacchetti trasmessi al secondo negli ultimi cinque minuti. Le velocità in entrata e in uscita di cinque minuti dovrebbero essere utilizzate solo come approssimazione del traffico al secondo durante un determinato periodo di cinque minuti. Questi tassi sono medie ponderate in modo esponenziale con una costante temporale di cinque minuti. Prima che la media sia all'interno del 2% della velocità istantanea di un flusso di traffico uniforme in quel periodo, devono passare quattro costanti di tempo.
input pacchetti	Numero totale di pacchetti privi di errori ricevuti dal sistema.
byte	Numero totale di byte, inclusi i dati e l'incapsulamento MAC, nei pacchetti privi di errori ricevuti dal sistema.
nessun buffer	Numero di pacchetti ricevuti scartati a causa della mancanza di spazio di buffer nel sistema principale. Confrontare con conteggio ignorato. I temporali di trasmissione sulle reti Ethernet e le esplosioni di rumore sulle linee seriali sono spesso responsabili di nessun evento di buffer di input.
Ricevuti... trasmissioni	Numero totale di pacchetti broadcast o multicast ricevuti dall'interfaccia.
runts	Numero di pacchetti che vengono scartati perché sono più piccoli delle dimensioni minime del pacchetto del supporto.
giants	Numero di pacchetti ignorati perché superano le dimensioni massime del supporto.
errori di input	Numero totale di conteggi senza buffer, runt, giganti, CRC, frame, sovraccarico, ignorato e interruzione. Anche altri errori correlati all'input possono incrementare il conteggio, pertanto questa somma potrebbe non quadrare con gli altri conteggi.
CRC	Il controllo di ridondanza ciclico generato dalla stazione di origine o dal dispositivo più lontano non corrisponde al checksum calcolato dai dati ricevuti. In un collegamento seriale, i CRC indicano solitamente disturbi, colpi di guadagno o altri problemi di trasmissione sul collegamento dati.
telaio	Numero di pacchetti ricevuti erroneamente con un errore CRC e un numero di ottetti non intero. Su una linea seriale, questo è in genere il risultato di disturbi o di altri problemi di trasmissione.
sovraccarico	Numero di volte in cui l'hardware del ricevitore seriale non è stato in grado di trasferire i dati ricevuti a un buffer hardware perché la frequenza di input superava la capacità del ricevitore di gestire i dati.
ignorato	Numero di pacchetti ricevuti ignorati dall'interfaccia perché l'hardware dell'interfaccia ha esaurito i buffer interni. Tempeste di trasmissione e raffiche di rumore possono aumentare il numero ignorato.
interrompere	Sequenza non valida di un bit su un'interfaccia seriale. Ciò in genere indica un problema di clock tra l'interfaccia seriale e l'apparecchiatura di collegamento dati.
transizioni portanti	Numero di volte in cui il segnale di rilevamento della portante di un'interfaccia seriale è cambiato di stato. Ad esempio, se il DCD (Data Carrier Detection) si disattiva e si attiva, il contatore di transizione della portante verrà incrementato due volte. Indica problemi relativi al modem o alla linea se lo stato della linea di rilevamento vettore cambia spesso.
output pacchetti	Numero totale di messaggi trasmessi dal sistema.
output byte	Numero totale di byte, inclusi i dati e l'incapsulamento MAC, trasmessi dal sistema.
sottocarico	Numero di volte in cui il trasmettitore è stato eseguito più rapidamente di quanto il router possa gestire. È possibile che non venga mai segnalato su alcune interfacce.
errori di output	Somma di tutti gli errori che hanno impedito la trasmissione finale dei datagrammi dall'interfaccia esaminata. Si noti che questa condizione potrebbe non essere in linea con la somma degli errori di output enumerati, in quanto alcuni datagrammi possono presentare più errori e altri errori che non rientrano in nessuna delle categorie specificamente tabulate.
collisioni	Numero di messaggi ritrasmessi a causa di una collisione Ethernet. In genere ciò è dovuto a una LAN sovraestesa (ossia un cavo Ethernet o ricetrasmettitore troppo lungo, più di due ripetitori tra le stazioni o troppi ricetrasmettitori multiporta a cascata). Alcune collisioni sono normali. Tuttavia, se il vostro tasso di collisione sale fino a circa il 4% o 5%, dovreste considerare la possibilità di verificare che non ci siano apparecchiature difettose sul segmento e/o spostare alcune stazioni esistenti in un nuovo segmento. Un pacchetto in collisione viene contato solo una volta nei pacchetti di output.
ripristino dell'interfaccia	Numero di volte in cui un'interfaccia è stata completamente reimpostata. Questo problema può verificarsi se i pacchetti accodati per la trasmissione non vengono inviati entro diversi secondi. Su una linea seriale, il problema può essere causato da un modem che non fornisce il segnale dell'orologio di trasmissione o da un problema del cavo. Se il sistema rileva che la linea di rilevamento portante di un'interfaccia seriale è attiva ma il protocollo di linea non è attivo, l'interfaccia viene periodicamente reimpostata nel tentativo di riavviarla. La reimpostazione dell'interfaccia può avvenire anche in caso di loopback o arresto dell'interfaccia.
riavvii	Numero di riavvii del controller a causa di errori.
indicazioni di allarme, allarmi remoti, rx LOF, rx LOS	Numero di allarmi CSU/DSU e numero di occorrenze di ricezione perdita di frame e ricezione perdita di segnale.
BER inattivo, NELR inattivo, FELR inattivo	Stato dei contatori G.703-E1 per l'allarme della frequenza di errore di bit (BER), il telecomando del loop near-end (NELR) e il telecomando del loop remoto (FELR). Non è possibile impostare i valori NELR o FELR.

Risoluzione dei problemi T1

In questa sezione vengono descritte le tecniche e le procedure per la risoluzione dei problemi relativi ai circuiti T1 per i clienti che utilizzano la connessione remota.

Risoluzione dei problemi con il comando show controller t1

Con questo comando viene visualizzato lo stato del controller specifico dell'hardware del controller. Le informazioni visualizzate sono in genere utili per le attività di diagnostica eseguite esclusivamente dal personale di supporto tecnico.

L'NMP (Network Management Processor) o il MIP (MultiChannel Interface Processor) può interrogare gli adattatori porte per determinarne lo stato corrente. Eseguire un comando show controller t1 per visualizzare le statistiche sul collegamento T1.

Se si specificano uno slot e un numero di porta, verranno visualizzate le statistiche per ogni periodo di 15 minuti. Il comando show controller t1 EXEC fornisce informazioni per la risoluzione logica dei problemi dei livelli fisici e dei livelli di collegamento dati. In questa sezione viene descritto come risolvere logicamente i problemi con il comando show controller t1.

La maggior parte degli errori T1 è causata da linee non configurate correttamente. Verificare che la codifica della linea, il framing e l'origine dell'orologio siano configurati in base ai suggerimenti del provider di servizi.

show controller t1 Condizioni

Il controller T1 può trovarsi in uno dei tre stati seguenti.

• Inattivo

• Giù

• Su

Il controller T1 è disattivato a livello amministrativo?

Il controller è disattivato a livello amministrativo quando è stato arrestato manualmente. Per correggere l'errore, riavviare il controller.

1. Accedere alla modalità di abilitazione.

   maui-nas-03>en
   Password: 
   maui-nas-03#

2. Accedere alla modalità di configurazione globale.

   maui-nas-03#configure terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   maui-nas-03(config)#

3. Accedere alla modalità di configurazione del controller.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#

4. Riavviare il controller.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

La linea è alta?

Se il controller T1 e la linea non sono attivi, verificare se nell'output show controller t1 EXEC viene visualizzato uno dei seguenti messaggi:

• Il ricevitore ha una perdita di frame

• Il ricevitore ha una perdita di segnale

Se il ricevitore T1 ha una perdita di frame:

Attenersi alla seguente procedura se il ricevitore T1 ha una perdita di frame:

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. È possibile controllare il formato del frame del controller dalla configurazione in esecuzione o dall'output del comando show controller t1.

   Per modificare il formato di frame, utilizzare il frame {SF} | ESF} nella modalità di configurazione del controller come mostrato di seguito:

   maui-nas-03#configure terminal
   

   Immettere i comandi di configurazione, uno per riga. Termina con CNTL/Z.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#framing esf
   

2. Provare con l'altro formato di frame per verificare se l'allarme viene cancellato.

3. Modificare l'impostazione di build-out della linea utilizzando la proprietà cablelength {long | short}.

Line Build out (LBO) compensa la perdita di decibel in base alla distanza dal dispositivo al primo ripetitore nel circuito. Una maggiore distanza tra il dispositivo e il ripetitore richiede che la forza del segnale sul circuito sia potenziata per compensare la perdita su quella distanza.

Per ulteriori informazioni sulle impostazioni predefinite, consultare il provider di servizi e la guida di riferimento dei comandi di Cisco IOSÒ.

Se il problema persiste, passare alla sezione seguente "Se il ricevitore T1 ha perdita di segnale".

Se Il Ricevitore T1 Perde Il Segnale:

Attenersi alla seguente procedura se il ricevitore T1 presenta una perdita di segnale:

1. Verificare che il cavo tra la porta di interfaccia e l'apparecchiatura del provider di servizi T1 (o l'apparecchiatura terminale T1) sia collegato correttamente. Verificare che il cavo sia collegato alle porte corrette. Se necessario, correggere le connessioni dei cavi.

2. Controllare l'integrità dei cavi. Cercare interruzioni o altre anomalie fisiche nel cavo. Accertarsi che i pin siano impostati correttamente. Se necessario, sostituire il cavo.

3. Controllare i connettori dei cavi. L'inversione delle coppie di trasmissione e ricezione o di una coppia di ricezione aperta può causare errori. Impostare la coppia di ricezione sulle righe 1 e 2. Impostare la coppia di trasmissione sulle righe 4 e 5.

   I pin di un jack RJ-45 sono numerati da 1 a 8. Il pin 1 è il pin più a sinistra quando si guarda il jack con i pin metallici rivolti verso di sé. Fate riferimento alla figura riportata di seguito.

   Figura 15-10: Cavo RJ-45

   

4. Provare a utilizzare un cavo di rollover.

Eseguire il comando show controller t1 EXEC dopo ciascuna fase per verificare se il controller presenta errori.

Verificare che la linea sia in modalità loopback dall'output show controller t1. Una riga deve essere in modalità loopback solo a scopo di test.

Per disattivare il loopback, utilizzare il comando no loopback nella modalità di configurazione del controller, come mostrato di seguito:

maui-nas-03(config-controlle)#no loopback

Se sul controller vengono visualizzati avvisi:

Controllare l'output del comando show controller per verificare se il controller visualizza allarmi.

Ora discuteremo dei vari allarmi e della procedura necessaria per correggerli.

Receive (RX) Alarm Indication Signal (AIS) (Blu):

Un segnale di allarme ricevuto (AIS) indica che si verifica un allarme sulla linea a monte dell'apparecchiatura collegata alla porta.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. In caso contrario, modificare il formato di frame sul controller in modo che corrisponda a quello della linea.

2. Contattare il provider di servizi per verificare la presenza di errori di configurazione nella rete Telco.

Receive (Rx) Remote Alarm Indication (RAI) (Giallo):

Una ricezione RAI indica che l'apparecchiatura remota ha un problema con il segnale che riceve dall'apparecchiatura a monte.

1. Inserire un cavo di loopback esterno nella porta. Per creare un plug di loopback, consultare la sezione "Creazione di un plug di loopback" più avanti nel capitolo.

2. Verificare se sono presenti allarmi. Se non vengono visualizzati allarmi, è probabile che l'hardware locale sia in buone condizioni. In tal caso:

   1. Controllare il cablaggio. Per ulteriori informazioni, vedere la sezione "Se il ricevitore T1 ha perdita di segnale".

   2. Controllare le impostazioni dell'estremità remota e verificare che corrispondano alle impostazioni della porta.

   3. Se il problema persiste, contattare il provider di servizi.

3. Rimuovere la spina di loopback e ricollegare la linea T1.

4. Controllare il cablaggio. Per ulteriori informazioni, vedere la sezione "Se il ricevitore T1 ha perdita di segnale".

5. Spegnere e riaccendere il router.

6. Collegare la linea T1 a una porta diversa. Configurare la porta con le stesse impostazioni della linea. Se il problema non persiste, il problema è causato da una porta:

   1. Ricollegare la linea T1 alla porta originale.

   2. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore T1".

      Se il problema persiste:

7. Eseguire un test del loop hardware come descritto nella sezione "Esecuzione del test del plug-in di loopback hardware".

8. Sostituire la scheda controller T1.

9. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore T1".

Trasmettitore che invia un allarme remoto (rosso):

Un allarme rosso viene dichiarato quando la CSU non può sincronizzarsi con il modello di framing sulla linea T1.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. In caso contrario, modificare il formato di frame sul controller in modo che corrisponda a quello della linea.

2. Controllare le impostazioni dell'estremità remota e verificare che corrispondano alle impostazioni della porta.

3. Contattare il provider di servizi.

Trasmissione (Tx) - Indicazione allarme remoto (RAI) (giallo):

Una trasmissione RAI all'interfaccia indica che l'interfaccia ha un problema con il segnale che riceve dall'apparecchiatura remota.

1. Controllare le impostazioni dell'estremità remota e verificare che corrispondano alle impostazioni della porta.

2. La trasmissione RAI deve essere accompagnata da un altro allarme che indichi la natura del problema che la porta/scheda T1 ha con il segnale proveniente dall'apparecchiatura remota.

Risolvere i problemi relativi a tale condizione per risolvere il problema della trasmissione RAI.

Trasmettitore (Tx) AIS (Blu):

Per correggere l'impostazione dell'opzione AIS (blu) di trasmissione (Tx), procedere come segue.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. In caso contrario, correggere la mancata corrispondenza.

2. Spegnere e riaccendere il router.

3. Collegare la linea T1 a una porta diversa. Configurare la porta con le stesse impostazioni della linea.

4. Eseguire un test del loop hardware come descritto nella sezione "Esecuzione del test del plug-in di loopback hardware".

5. Sostituire la scheda controller T1.

6. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore T1".

Risoluzione dei problemi di errore T1

Il comando show controller t1 EXEC restituisce messaggi di errore che possono essere utilizzati per risolvere i problemi. Verranno ora illustrati diversi messaggi di errore e verrà spiegato come correggere gli errori.

Per verificare se i contatori degli errori stanno aumentando, eseguire ripetutamente il comando show controller t1. Annotare i valori dei contatori per l'intervallo corrente.

Consultate il vostro provider di servizi per le impostazioni di framing e linecoding. Una buona regola pratica consiste nell'utilizzare il lincoding B8ZS con il framing ESF e il lincoding AMI con il framing SF.

Il contatore delle sedie di slittamento è in aumento:

La presenza di scivoloni su una linea T1 indica un problema di clock. Il provider T1 (Telco) fornirà la temporizzazione alla quale sincronizzare CPE (Customer Premises Equipment).

1. Verificare che l'origine dell'orologio provenga dalla rete. Per verificare questa condizione, cercare Sorgente orologio - Primario linea.

   Nota: se in un server di accesso sono presenti più T1, solo uno può essere il server principale, mentre gli altri T1 possono derivare l'orologio dal server principale. In tal caso, verificare che la linea T1 designata come sorgente principale dell'orologio sia configurata correttamente.

2. Impostare correttamente l'origine dell'orologio T1 dalla modalità di configurazione del controller.

   maui-nas-03(config-controlle)#clock source line primary
   

Aumento del contatore di secondi di perdita di frame:

Attenersi alla seguente procedura quando il contatore di perdita di fotogrammi secondi aumenta.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. È possibile verificare questa condizione cercando il frame {ESF|SF} nell'output show controller t1.

2. Per modificare il formato di frame, utilizzare il frame {SF | ESF} nella modalità di configurazione del controller come mostrato di seguito:

   maui-nas-03(config-controlle)#framing esf
   

3. Modificare la lunghezza della linea utilizzando la lunghezza del cavo {long | short}.

Per ulteriori informazioni sulle impostazioni predefinite, consultare il provider di servizi e la guida di riferimento dei comandi di Cisco IOSÒ.

Le violazioni del codice di linea sono in aumento:

Attenersi alla procedura seguente quando le violazioni del codice di linea sono in aumento.

1. Verificare che il codec di linea configurato sulla porta corrisponda al formato di framing della linea. È possibile verificare questa condizione cercando il codice linea {B8ZS|AMI} nell'output show controller t1.

2. Per modificare il linecoding, utilizzare il linecode {ami | b8zs} nella modalità di configurazione del controller, come mostrato di seguito:

   maui-nas-03(config-controlle)#linecode b8zs
   

3. Modificare la lunghezza della linea utilizzando la lunghezza del cavo {long | short}.

Per ulteriori informazioni sulle impostazioni di integrazione, consultare il provider di servizi e la guida di riferimento ai comandi di Cisco IOS®.

Verifica della configurazione corretta del tipo di switch ISDN e del gruppo PRI

Utilizzare il comando show running-config per verificare se il tipo di switch ISDN e gli intervalli di tempo del gruppo PRI sono configurati correttamente. Contattare il provider di servizi per i valori corretti.

Per modificare il tipo di switch ISDN e il gruppo PRI:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-5ess
maui-nas-03(config)#controller t1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-24

Verifica del canale di segnalazione

Se i contatori degli errori non aumentano ma il problema persiste, verificare che il canale di segnalazione sia attivo e configurato correttamente.

1. Eseguire il comando show interface serial x:23, dove x deve essere sostituito dal numero dell'interfaccia.

2. Verificare che l'interfaccia sia attiva. Se l'interfaccia non è attiva, usare il comando no shutdown per riattivarla.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

3. Verificare che l'incapsulamento sia PPP. Se l'interfaccia non utilizza il protocollo PPP, usare il comando encapsulation ppp in modalità di configurazione interfaccia per correggerlo.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Verificare se il loopback è impostato. Il loopback deve essere impostato solo a scopo di test. Utilizzare il comando no loopback per rimuovere i loopback.

   maui-nas-03(config-if)#no loopback
   

5. Spegnere e riaccendere il router.

6. Se il problema persiste, contattare il provider di servizi o Cisco TAC

Risoluzione dei problemi di un PRI

Ogni volta che si risolve un problema con un PRI, è necessario verificare se T1 funziona correttamente su entrambe le estremità. Se i problemi di livello 1 sono stati risolti, come descritto in precedenza, prendere in considerazione i problemi di livello 2 e 3.

Risoluzione dei problemi con il comando show isdn status

Il comando show isdn status viene usato per visualizzare un'istantanea di tutte le interfacce ISDN. Visualizza lo stato dei livelli 1, 2 e 3.

1. Verificare che il livello 1 sia attivo.

   Lo stato del livello 1 deve sempre essere ATTIVO a meno che T1 non sia inattivo. Se show isdn status indica che il layer 1 è DISATTIVATO, si è verificato un problema con la connettività fisica sulla linea T1. Vedere la sezione "Il controller T1 è inattivo?"

   Verificare inoltre che T1 non sia disattivato a livello amministrativo. Usare il comando no shutdown per sollevare il controller T1.

2. Verificare se lo stato del layer 2 è MULTIPLE_FRAME_DEFINED

Lo stato del layer 2 desiderato è Multiple_Frame_Established, il che indica che si stanno scambiando frame di layer 2 e che l'inizializzazione del layer 2 è stata completata.

Se il layer 2 non è Multiple_Frame_Established, usare il comando show controller t1 EXEC per diagnosticare il problema. Fare riferimento alla sezione Risoluzione dei problemi utilizzando il comando show controller t1 di questo capitolo.

Poiché show isdn status è un'istantanea dello stato corrente, è possibile che il livello 2 salti verso l'alto e verso il basso nonostante indichi Multi_Frame_Established. Utilizzare debug isdn q921 per verificare che il layer 2 sia stabile.

Il comando debug isdn q921 visualizza le procedure di accesso al livello di collegamento dati (livello 2) in corso al router sul canale D.

Verificare di essere configurati per visualizzare i messaggi di debug utilizzando la console di registrazione o il comando terminal monitor, se necessario.

Nota: in un ambiente di produzione verificare che la registrazione della console sia disabilitata. Immettere il comando show logging. Se la registrazione è attivata, il server di accesso potrebbe bloccarsi in modo intermittente non appena la porta della console si sovraccarica di messaggi di registro. Immettere il comando no logging console.

Nota: se debug isdn q921 è attivato e non si ricevono output di debug, chiamare o ripristinare il controller per ottenere gli output di debug.

1. Verificare che il layer 2 sia stabile.

   Osservare gli output del comando debug per i messaggi che indicano che il servizio non è attivo o inattivo. Se vengono visualizzati i seguenti tipi di output di debug, la linea non è stabile.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed 
   to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   
   

   Se il layer 2 non sembra stabile, vedere la sezione "Risoluzione dei problemi di errore T1" più indietro in questo capitolo.

2. Verificare che vengano visualizzati solo i messaggi SAPI su entrambi i lati di trasmissione (TX) e ricezione (RX).

   Mar 20 10:06:52.505: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:23: TX ->  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Verificare che non vengano visualizzati messaggi SABME, il che indica che il layer 2 sta tentando di reinizializzare. Questa condizione si verifica in genere quando si trasmettono richieste di polling (RRp) e non si riceve risposta dallo switch (RRf) o viceversa. Di seguito sono riportati alcuni esempi di messaggi SABME.

   Mar 20 10:06:21.702: ISDN Se0:23: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:23: TX ->  SABMEp sapi = 0  tei = 0

   Se vengono visualizzati messaggi SABME, usare il comando show running-config per verificare se il tipo di switch ISDN e i timeslot del gruppo PRI sono configurati correttamente. Contattare il provider di servizi per i valori corretti.

   Per modificare il tipo di switch ISDN e il gruppo PRI:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-5ess
   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-24
   

4. Verificare che il canale D sia attivo utilizzando il comando show interfaces serial x:23.

   Se il canale D non è attivo, usare il comando no shutdown per attivarlo:

   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

5. Verificare se l'incapsulamento è PPP. In caso contrario, usare il comando encapsulation ppp per impostare l'incapsulamento.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Verificare che l'interfaccia sia in modalità loopback. Per il funzionamento normale, l'interfaccia non deve essere in modalità loopback.

   maui-nas-03(config-if)#no loopback
   

7. Spegnere e riaccendere il router.

8. Se il problema persiste, contattare il provider di servizi o il centro TAC Cisco.

Esecuzione del test del plug-in di loopback hardware

Il test del plug-in di loopback dell'hardware può essere utilizzato per verificare se il router presenta errori. Se un router supera un test del plug-in di loopback hardware, il problema si verifica in un altro punto della linea.

Creare un plug-in di loopback:

Per creare un plug di loopback, attenersi alla procedura descritta di seguito.

1. Utilizzare le sfinestrature per tagliare un cavo RJ-45 o RJ-48 funzionante in modo che vi siano cinque pollici di cavo e il connettore sia collegato ad esso.

2. Staccate i cavi.

3. Avvitare i fili dai pin 1 e 4.

4. Avvitare i fili dai pin 2 e 5.

I pin di un jack RJ-45/48 sono numerati da 1 a 8. Il pin 1 è il pin più a sinistra quando si guarda il jack con i pin metallici rivolti verso di sé.

Esecuzione del test del plug-in di loopback

Per eseguire il test del plug di loopback, attenersi alla seguente procedura.

1. Inserire la spina nella porta T1 in questione.

2. Salvare la configurazione del router utilizzando il comando write memory.

   maui-nas-03#write memory
   Building configuration...
   [OK]

3. Impostare l'incapsulamento su HDLC

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0
   maui-nas-03(config-if)#enc
   maui-nas-03(config-if)#encapsulation HDLC 
   maui-nas-03(config-if)#^Z
   

4. Per verificare se l'interfaccia ha un indirizzo IP, usare il comando show running-config.

   Se l'interfaccia non ha un indirizzo IP, ottenere un indirizzo univoco e assegnarlo all'interfaccia con una subnet mask di 255.255.255.0.

   maui-nas-03(config)#ip address 172.22.53.1 255.255.255.0
   

5. Cancellare i contatori dell'interfaccia utilizzando il comando clear counters.

   maui-nas-03#clear counters
   Clear "show interfaces" counters on all interfaces [confirm]
   maui-nas-03#

6. Eseguire il test ping esteso come descritto nella sezione "Uso dei test ping estesi" più indietro in questo capitolo.

Risoluzione dei problemi E1

In questa sezione vengono descritte le tecniche e le procedure per la risoluzione dei problemi relativi ai circuiti E1 per i clienti che utilizzano la connessione remota.

Risoluzione dei problemi con il comando show controller e1

Con questo comando viene visualizzato lo stato del controller specifico dell'hardware del controller. Le informazioni visualizzate sono in genere utili per le attività di diagnostica eseguite esclusivamente dal personale di supporto tecnico.

Il protocollo NMP o MIP può interrogare gli adattatori di porte per determinarne lo stato corrente. Eseguire un comando show controller e1 per visualizzare le statistiche sul collegamento E1. Se si specifica uno slot e un numero di porta, verranno visualizzate le statistiche per ogni periodo di 15 minuti.

Il comando show controller e1 EXEC fornisce informazioni per la risoluzione logica dei problemi dei livelli fisici e dei livelli di collegamento dati. In questa sezione viene descritto come risolvere logicamente i problemi utilizzando il comando show controller e1.

La maggior parte degli errori E1 è causata da linee non configurate correttamente. Verificare che la codifica della linea, il framing, l'origine dell'orologio e la terminazione della linea (bilanciata o non bilanciata) siano configurati in base alle raccomandazioni del provider di servizi.

show controller e1 Condizioni

Il controller E1 può trovarsi in uno dei tre stati seguenti.

• Inattivo

• Giù

• Su

Il controller E1 è disattivato a livello amministrativo?

Il controller è disattivato a livello amministrativo quando è stato arrestato manualmente. Per correggere l'errore, riavviare il controller.

1. Accedere alla modalità di abilitazione.

   maui-nas-03>enable
   Password: 
   maui-nas-03#

2. Accedere alla modalità di configurazione globale.

   maui-nas-03#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#

3. Accedere alla modalità di configurazione del controller.

   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#

4. Riavviare il controller.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

La linea è alta?

Se la linea E1 non è attiva, verificare che la configurazione della linea sia corretta e corrisponda alle impostazioni dell'estremità remota.

1. Controllare l'inquadratura della linea e dell'estremità remota. Per le linee E1, il frame è CRC4 o noCRC4

2. Controllare l'allineamento della linea e dell'estremità remota. La codifica è AMI o HDB3.

3. Verificare che la terminazione di linea sia impostata per bilanciato o non bilanciato (75 ohm o 120 ohm).

Per ulteriori informazioni sulle impostazioni corrette, contattare il provider di servizi. Apportare le modifiche necessarie ai dispositivi terminali locali o remoti.

Se il controller E1 e la linea non sono attivi, verificare se nell'output show controller e1 EXEC viene visualizzato uno dei seguenti messaggi:

• Il ricevitore ha una perdita di frame

• Il ricevitore ha una perdita di segnale

Se il ricevitore E1 ha una perdita di frame:

Attenersi alla seguente procedura se il ricevitore E1 ha una perdita di frame.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. È possibile controllare il formato di frame del controller dalla configurazione in esecuzione o dall'output del comando show controller e1.

   Per modificare il formato di frame, utilizzare il comando framing {CRC4 | no CRC4} nella modalità di configurazione del controller, come mostrato di seguito:

   maui-nas-03#configure terminal 
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#controller E1 0
   maui-nas-03(config-controlle)#framing CRC4
   

2. Provare con l'altro formato di frame per verificare se l'allarme viene cancellato.

   Se il problema persiste, passare alla sezione seguente "Se il ricevitore E1 ha perdita di segnale".

3. Controllare il formato di frame sull'estremità remota.

4. Controllare la codifica della linea sull'estremità remota.

Se Il Ricevitore E1 Perde Il Segnale:

Attenersi alla seguente procedura se il ricevitore E1 ha una perdita di segnale

1. Verificare che il cavo tra la porta di interfaccia e l'apparecchiatura del provider di servizi E1 (o l'apparecchiatura terminale E1) sia collegato correttamente. Verificare che il cavo sia collegato alle porte corrette. Se necessario, correggere le connessioni dei cavi.

2. Controllare l'integrità dei cavi. Cercare interruzioni o altre anomalie fisiche nel cavo. Accertarsi che i pin siano impostati correttamente. Se necessario, sostituire il cavo.

3. Controllare i connettori dei cavi. L'inversione delle coppie di trasmissione e ricezione o di una coppia di ricezione aperta può causare errori. Impostare la coppia di ricezione sulle righe 1 e 2. Impostare la coppia di trasmissione sulle righe 4 e 5.

   I pin di un jack RJ-48 sono numerati da 1 a 8. Il pin 1 è il pin più a sinistra quando si guarda il jack con i pin metallici rivolti verso di sé. Per ulteriori informazioni, fate riferimento alla figura riportata di seguito.

   Figura 15-11: Cavo RJ-45

   

4. Provare a utilizzare un cavo di rollover.

5. Verificare se sono presenti errori di blocco di estremità remota. In tal caso, il problema è dovuto al lead di ricezione sull'estremità locale. Contatta il TAC per ulteriore assistenza.

Eseguire il comando show controller e1 EXEC dopo ciascuna fase per verificare se il controller presenta errori.

Se la linea è in modalità loopback:

Verificare che la linea sia in modalità loopback dall'output show controller e1. Una riga deve essere in modalità loopback solo a scopo di test.

Per disattivare il loopback, utilizzare il comando no loopback nella modalità di configurazione del controller, come mostrato di seguito:

maui-nas-03(config-controlle)#no loopback

Se sul controller vengono visualizzati avvisi:

Controllare l'output del comando show controller per verificare se il controller visualizza allarmi.

Ora discuteremo dei vari allarmi e della procedura necessaria per correggerli.

Il Ricevitore (Rx) Dispone Di Un Allarme Remoto:

Un allarme remoto ricevuto indica che si verifica un allarme sulla linea a monte dell'apparecchiatura collegata alla porta.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. In caso contrario, modificare il formato di frame sul controller in modo che corrisponda a quello della linea.

2. Controllare l'impostazione della codifica della linea sull'apparecchiatura remota. Contattare il provider di servizi per le impostazioni corrette. Correggere eventuali errori di configurazione.

3. Inserire un cavo di loopback esterno nella porta. Per creare un plug di loopback, vedere la sezione "Esecuzione del test del plug di loopback hardware" più indietro nel capitolo.

4. Verificare se sono presenti allarmi. Se non vengono visualizzati allarmi, è probabile che l'hardware locale sia in buone condizioni. In tal caso:

   1. Controllare il cablaggio. Per ulteriori informazioni, consultare la sezione "Se il ricevitore E1 ha perdita di segnale".

   2. Controllare le impostazioni dell'estremità remota e verificare che corrispondano alle impostazioni della porta.

   3. Se il problema persiste, contattare il provider di servizi.

5. Rimuovere la spina di loopback e ricollegare la linea E1.

6. Controllare il cablaggio. Per ulteriori informazioni, vedere la sezione "Se il ricevitore E1 ha perdita di segnale".

7. Spegnere e riaccendere il router.

8. Collegare la linea E1 a una porta diversa. Configurare la porta con le stesse impostazioni della linea. Se il problema non persiste, il problema è causato da una porta:

   1. Ricollegare la linea E1 alla porta originale.

   2. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore E1".

      Se il problema persiste:

9. Eseguire un test del loop hardware come descritto nella sezione "Esecuzione del test del plug-in di loopback hardware".

10. Sostituire la scheda controller E1.

11. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore E1".

Trasmettitore che invia un allarme remoto (rosso):

Un allarme rosso viene dichiarato quando la CSU non può sincronizzarsi con il modello di framing sulla linea E1.

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. In caso contrario, modificare il formato di frame sul controller in modo che corrisponda a quello della linea.

2. Controllare le impostazioni dell'estremità remota e verificare che corrispondano alle impostazioni della porta.

3. Inserire un cavo di loopback esterno nella porta. Per creare un plug di loopback, vedere la sezione "Esecuzione del test del plug di loopback hardware" più indietro nel capitolo.

4. Verificare se sono presenti allarmi. Se non vengono visualizzati allarmi, è probabile che l'hardware locale sia in buone condizioni. In tal caso:

   1. Controllare il cablaggio. Per ulteriori informazioni, consultare la sezione "Se il ricevitore E1 ha perdita di segnale".

   2. Se il problema persiste, contattare il provider di servizi.

5. Collegare la linea E1 a una porta diversa. Configurare la porta con le stesse impostazioni della linea. Se il problema non persiste, il guasto è causato dalla porta uno.

   1. Ricollegare la linea E1 alla porta originale.

   2. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore E1".

      Se il problema persiste:

6. Eseguire un test del loop hardware come descritto nella sezione "Esecuzione del test del plug-in di loopback hardware".

7. Sostituire la scheda controller E1.

8. Procedere alla sezione "Risoluzione dei problemi relativi agli eventi di errore E1".

9. Contattare il provider di servizi.

Risoluzione dei problemi relativi agli eventi di errore E1

Il comando show controller e1 EXEC restituisce messaggi di errore che possono essere utilizzati per risolvere i problemi. Verranno ora illustrati diversi messaggi di errore e verrà spiegato come correggere gli errori.

Per verificare se i contatori degli errori stanno aumentando, eseguire ripetutamente il comando show controller e1. Annotare i valori dei contatori per l'intervallo corrente. Consultate il vostro provider di servizi per le impostazioni di framing e linecoding.

Il contatore delle sedie di slittamento è in aumento:

La presenza di scivoloni sulle linee E1 indica un problema di clock. Il provider E1 (Telco) fornirà la temporizzazione alla quale sincronizzare CPE (Customer Premises Equipment).

1. Verificare che l'origine dell'orologio provenga dalla rete. Per verificare questa condizione, cercare Sorgente orologio - Primario linea.

   Nota: se in un server di accesso sono presenti più E1, solo uno può essere quello principale, mentre gli altri E1 possono derivare l'orologio da quello principale. In tal caso, verificare che la linea E1 designata come origine dell'orologio principale sia configurata correttamente.

2. Impostare correttamente l'origine dell'orologio E1 dalla modalità di configurazione del controller.

   maui-nas-03(config-controlle)#clock source line primary
   

Aumento del contatore di secondi di perdita di frame:

Attenersi alla procedura seguente quando aumenta il contatore dei secondi di perdita di frame:

1. Verificare che il formato di frame configurato sulla porta corrisponda al formato di frame della linea. È possibile verificare questa condizione cercando il frame {CRC4|no CRC4} nell'output show controller e1.

2. Per modificare il formato di frame, utilizzare il comando framing {CRC4 | no CRC4} nella modalità di configurazione del controller, come mostrato di seguito:

   maui-nas-03(config-controlle)#framing crc4
   

Le violazioni dei codici di linea sono in aumento:

Attenersi alla procedura seguente quando le violazioni del codice di linea sono in aumento.

1. Verificare che il codec di linea configurato sulla porta corrisponda al formato di framing della linea. È possibile verificare questa condizione cercando il codice di linea {AMI/HDB3} nell'output show controller e1.

2. Per modificare l'indicizzazione della linea, utilizzare il codice di linea {ami | hdb3} nella modalità di configurazione del controller, come mostrato di seguito:

   maui-nas-03(config-controlle)#linecode ami
   

Verifica della configurazione corretta del tipo di switch ISDN e del gruppo PRI

Utilizzare il comando show running-config per verificare se il tipo di switch ISDN e gli intervalli di tempo del gruppo PRI sono configurati correttamente. Contattare il provider di servizi per i valori corretti.

Per modificare il tipo di switch ISDN e il gruppo PRI:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-net5
maui-nas-03(config)#controller e1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-31

Verifica del canale di segnalazione

Se i contatori degli errori non aumentano ma il problema persiste, verificare che il canale di segnalazione sia attivo e configurato correttamente.

1. Eseguire il comando show interface serial x:15, dove x deve essere sostituito dal numero dell'interfaccia.

2. Verificare che l'interfaccia sia attiva. Se l'interfaccia non è attiva, usare il comando no shutdown per riattivarla.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

3. Verificare che l'incapsulamento sia PPP. Se l'interfaccia non utilizza il protocollo PPP, usare il comando encapsulation ppp in modalità di configurazione interfaccia per correggerlo.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Verificare se il loopback è impostato. Il loopback deve essere impostato solo a scopo di test. Utilizzare il comando no loopback per rimuovere i loopback.

   maui-nas-03(config-if)#no loopback
   

5. Spegnere e riaccendere il router.

6. Se il problema persiste, contattare il provider di servizi o il centro TAC Cisco.

Risoluzione dei problemi di un PRI

Quando si risolve un problema relativo a un sistema PRI, è necessario determinare se E1 funziona correttamente su entrambe le estremità. Se i problemi di livello 1 sono stati risolti come descritto in precedenza, prendere in considerazione i problemi di livello 2 e 3.

Risoluzione dei problemi con il comando show isdn status

Il comando show isdn status viene usato per visualizzare un'istantanea di tutte le interfacce ISDN. Visualizza lo stato dei livelli 1, 2 e 3.

1. Verificare che il livello 1 sia attivo.

   Lo stato del livello 1 deve sempre essere ATTIVO, a meno che E1 non sia inattivo.

   Se show isdn status indica che il layer 1 è DISATTIVATO, si è verificato un problema con la connettività fisica sulla linea E1. Vedere la sezione "Il controller E1 è disattivato a livello amministrativo?"

   Verificare inoltre che E1 non sia disattivato a livello amministrativo. Usare il comando no shutdown per riattivare il controller E1.

2. Verificate che lo stato del livello 2 sia MULTIPLE_FRAME_DEFINED.

Lo stato di layer 2 desiderato è Multiple_Frame_Established, che indica che è stato stabilito il protocollo di avvio tra lo switch ISDN e il dispositivo finale e che stiamo scambiando frame di layer 2.

Se il layer 2 non è Multiple_Frame_Established, usare il comando show controller e1 EXEC per diagnosticare il problema. Vedere la sezione "Risoluzione dei problemi relativi all'uso del comando show controller e1" in questo capitolo e la sezione "Risoluzione dei problemi relativi agli eventi di errore E1".

Poiché show isdn status è un'istantanea dello stato corrente, è possibile che il layer 2 stia rimbalzando verso l'alto e verso il basso nonostante indichi Multiple_Frame_Established. Per verificare che il layer 2 sia stabile, usare il comando debug isdn q921.

Utilizzo di debug q921

Il comando debug isdn q921 visualizza le procedure di accesso al livello di collegamento dati (livello 2) in corso al router sul canale D.

Verificare di essere configurati per visualizzare i messaggi di debug utilizzando la console di registrazione o il comando terminal monitor, a seconda delle esigenze.

Nota: in un ambiente di produzione verificare che la registrazione della console sia disabilitata. Immettere il comando show logging. Se la registrazione è attivata, il server di accesso potrebbe bloccarsi in modo intermittente non appena la porta della console si sovraccarica di messaggi di registro. Immettere il comando no logging console.

Nota: se debug isdn q921 è attivato e non si ricevono output di debug, chiamare o ripristinare il controller per ottenere gli output di debug.

1. Verificare che il layer 2 sia stabile. Osservare gli output del comando debug per i messaggi che indicano che il servizio non è attivo o inattivo. Se vengono visualizzati i seguenti tipi di output di debug, la linea non è stabile.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:15, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:15, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:15, TEI 0 
   changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:15, changed state to up
   
   

   Se il layer 2 non sembra stabile, vedere la sezione "Risoluzione dei problemi relativi agli eventi di errore E1" più indietro in questo capitolo.

2. Verificare che vengano visualizzati solo i messaggi SAPI su entrambi i lati di trasmissione (TX) e ricezione (RX).

   Mar 20 10:06:52.505: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:15: TX ->  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Verificare che non vengano visualizzati messaggi SABME, il che indica che il layer 2 sta tentando di reinizializzare. Questa condizione si verifica in genere quando si trasmettono richieste di polling (RRp) e non si riceve risposta dallo switch (RRf) o viceversa. Di seguito sono riportati alcuni esempi di messaggi SABME. Dovremmo ricevere una risposta dallo switch ISDN per i nostri messaggi SABME (frame UA ricevuto).

   Mar 20 10:06:21.702: ISDN Se0:15: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:15: TX ->  SABMEp sapi = 0  tei = 0

   Se vengono visualizzati messaggi SABME, usare il comando show running-config per verificare che il tipo di switch ISDN e i timeslot del gruppo PRI siano configurati correttamente. Contattare il provider di servizi per i valori corretti.

   Per modificare il tipo di switch ISDN e il gruppo PRI:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-net5
   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-31
   

4. Verificare che il canale D sia attivo utilizzando il comando show interfaces serial x:15.

   Se il canale D non è attivo, usare il comando no shutdown per attivarlo:

   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

5. Verificare se l'incapsulamento è PPP. In caso contrario, usare il comando encapsulation ppp per impostare l'incapsulamento.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Verificare che l'interfaccia sia in modalità loopback. Per il funzionamento normale, l'interfaccia non deve essere in modalità loopback.

   maui-nas-03(config-if)#no loopback
   

7. Spegnere e riaccendere il router.

8. Se il problema persiste, contattare il provider di servizi o il centro TAC Cisco.

Informazioni correlate

• Supporto tecnico – Cisco Systems

Cronologia delle revisioni