Risoluzione dei problemi relativi alla Primary Rate Interface (PRI) T1

Introduzione

In questo documento viene descritto come risolvere i problemi di una Primary Rate Interface (PRI) T1 e verificare che funzioni correttamente.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

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.

Premesse

Quando si esegue la risoluzione di un problema con PRI (Primary Rate Interface), verificare che T1 funzioni correttamente su entrambe le estremità. Il motivo è che il segnale PRI ISDN viene trasmesso sul layer fisico T1. Per verificare se il T1 Layer 1 funziona correttamente, usare il comando show controller t1. Verificare che non siano presenti errori in nessuno dei contatori. Verificare che il frame, la codifica della linea e l'origine dell'orologio siano configurati correttamente. Per ulteriori informazioni, consultare il diagramma di flusso T1 per la risoluzione dei problemi. Contattare il provider di servizi per le impostazioni corrette.

Una volta risolti i problemi nel layer 1 e azzerati i contatori show controller t1, è possibile concentrarsi sui layer 2 e 3 della segnalazione ISDN PRI.

Suggerimento: è possibile utilizzare il comando clear counters per ripristinare i contatori T1. Quando i contatori sono chiari, è possibile osservare facilmente se la linea T1 presenta errori. Tuttavia, tenere presente che questo comando cancella anche tutti gli altri contatori di interfaccia show. Di seguito è riportato un esempio:

maui-nas-03#clear counters
Clear "show interface" counters on all interfaces [confirm]
maui-nas-03#
*Apr 12 03:34:12.143: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console

Usare il comando show isdn status

Il comando show isdn status è molto utile per risolvere i problemi di segnalazione ISDN. Il comando show isdn status permette di visualizzare un riepilogo dello stato corrente di tutte le interfacce ISDN e dello stato dei layer 1, 2 e 3. Di seguito è riportato un esempio dell'output del comando show isdn status:

maui-nas-03#show isdn status
Global ISDN Switchtype = primary-5ess
ISDN Serial0:23 interface
        dsl 0, interface ISDN Switchtype = primary-5ess
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        5 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 5
        CCB:callid=7D5, sapi=0, ces=0, B-chan=9, calltype=DATA
        CCB:callid=7D6, sapi=0, ces=0, B-chan=10, calltype=DATA
        CCB:callid=7DA, sapi=0, ces=0, B-chan=11, calltype=DATA
        CCB:callid=7DE, sapi=0, ces=0, B-chan=1, calltype=DATA
        CCB:callid=7DF, sapi=0, ces=0, B-chan=2, calltype=DATA
    The Free Channel Mask:  0x807FF8FC
ISDN Serial1:23 interface
        dsl 1, interface ISDN Switchtype = primary-5ess
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Activated dsl 1 CCBs = 0
    The Free Channel Mask:  0x807FFFFF
    Total Allocated ISDN CCBs = 5

Per controllare lo stato dei livelli, completare i seguenti passaggi:

1. Verificare se il layer 1 è nello stato ACTIVE. Lo stato del layer 1 deve essere sempre ATTIVO a meno che T1 non sia inattivo.

   Se l'output del comando show isdn status indica che il layer 1 è DISATTIVATO, si è verificato un problema con la connettività fisica della linea T1. Se la linea è disattivata a livello amministrativo, usare il comando no shutdown per riavviare l'interfaccia.

2. Assicuratevi che il livello 2 sia nello stato MULTIPLE_FRAME_DEFINED. Questo è lo stato richiesto per il layer 2. Questo stato indica che il router ha ricevuto un messaggio ISDN SABME (Set Asynchronous Balanced Mode Extended) e ha risposto con un frame UA (Unnumber Acknowledge) per la sincronizzazione con lo switch Telco. Inoltre, devono esistere frame di layer 2 costanti (Receiver Ready, RR) tra i due dispositivi. In questo caso, il router e lo switch ISDN hanno inizializzato completamente il protocollo ISDN layer 2. Per informazioni su come identificare i messaggi SABME e RR, vedere la sezione Utilizzare il comando debug q921.

   Se il layer 2 non è nello stato MULTIPLE_FRAME_DEFINED, usare il comando debug isdn q921per diagnosticare il problema.

   Inoltre, il comando show isdn status visualizza un riepilogo dello stato corrente. Pertanto, il livello 2 può rimbalzare verso l'alto e verso il basso anche se indica uno stato MULTIPLE_FRAME_DEFINED. Per verificare che il layer 2 sia stabile, usare il comando debug isdn q921.

   A questo punto, usare il comando show controllers t1 per controllare nuovamente T1 e assicurarsi che non vi siano errori. In caso di errori, fare riferimento al diagramma di flusso T1 Risoluzione dei problemi.

Nell'esempio di output dello stato isdn, notare che T1 0 (il cui canale D è Serial 0:23) ha il layer 1 come ACTIVE e il layer 2 come MULTIPLE_FRAME_DEFINED per indicare che il canale di segnalazione funziona correttamente e scambia i frame di layer 2 con lo switch Telco. Il canale D (Serial1:23) per T1 1 ha il layer 1 ACTIVE, ma il layer 2 è TEI_ASSIGNMENT, il che indica che il PRI non scambia i frame del layer 2 con lo switch. Usare il comando show controller t1 x per controllare innanzitutto il circuito controller t1 e verificare se è pulito (ossia non contiene errori) prima di risolvere il problema di ISDN Layer 2 con debug isdn q921. Per ulteriori informazioni, consultare il diagramma di flusso T1 per la risoluzione dei problemi

Usare il comando debug isdn q921

Questo comando debug è utile quando si risolvono i problemi di segnalazione ISDN Layer 2. Il comando debug isdn q921 visualizza le procedure di accesso al livello di collegamento dati (livello 2) che si verificano sul router del canale D. Ciò può indicare se il problema dipende dal NAS, dallo switch Telco o dalla linea.

Utilizzare il comando logging console o terminal monitor per verificare di essere configurati per visualizzare i messaggi di debug.

Nota: in un ambiente di produzione, utilizzare il comando show logging per assicurarsi che la registrazione sulla console sia disabilitata. Se la console di registrazione è attivata, il server di accesso può interrompere le proprie funzioni in modo intermittente quando la porta della console è sovraccarica di messaggi di registro. Immettere il comando no logging console per disabilitare la registrazione sulla porta della console. per ulteriori informazioni, consultare le informazioni importanti sui comandi di debug.

Nota: se debug isdn q921 è attivato e non si ricevono output di debug, verificare innanzitutto che terminal monitor sia abilitato. Quindi provare a ripristinare il controller o il canale D per ottenere gli output di debug. Per ripristinare la linea, è possibile usare il comando clear controller t1 o clear interface serial x:23.

Completare questi passaggi per accertarsi che le procedure di accesso al livello di collegamento dati si verifichino sul router del canale D:

1. Verificare se il layer 2 è stabile. A tale scopo, cercare i messaggi nell'output del comando debug. Di seguito è riportato l'output del comando debug isdn q921 quando il controller T1 viene arrestato e non viene arrestato:

   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 la linea rimbalza verso l'alto o verso il basso, viene visualizzato un output simile a questo:

   %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
   %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed to up
   %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
   %LINK-3-UPDOWN: Interface Serial0:23, changed state to down

2. Se il layer 2 è stabile, il router e lo switch devono iniziare a sincronizzarsi tra loro. Sul display viene visualizzato il messaggio Set Asynchronous Balanced Mode Extended (SABME). Questo messaggio indica che il layer 2 tenta di inizializzare con l'altro lato. Entrambi i dispositivi possono inviare il messaggio e provare a inizializzare con l'altro dispositivo. Se il router riceve il messaggio SABME, deve restituire un frame di conferma senza numero (UAf). Infine, il router cambia lo stato del layer 2 in MULTIPLE_FRAME_DEFINED. Di seguito è riportato un esempio:

   *Apr 12 04:14:43.967: ISDN Se0:23: RX <- SABMEp c/r=1 sapi=0 tei=0
   
   *Apr 12 04:14:43.971: ISDN Se0:23: TX -> UAf c/r=1 sapi=0 tei=0
   
   

   Se lo switch riceve e riconosce l'interfaccia UAf, entrambi i dispositivi vengono sincronizzati e i pacchetti keepalive periodici vengono scambiati tra il router e lo switch ISDN. Questi messaggi sono in forma di Receiver Ready (Rf e RRp). I pacchetti keepalive vengono visualizzati a dieci secondi di distanza l'uno dall'altro e garantiscono la comunicazione tra le due parti. Ad esempio:

   *Apr 12 05:19:56.183: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
   
   *Apr 12 05:19:56.183: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
   *Apr 12 05:20:06.247: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
   
   *Apr 12 05:20:06.247: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
   *Apr 12 05:20:16.311: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
   
   *Apr 12 05:20:16.311: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
   
   

   

   Nota: vedere TX, RX e la freccia. TX indica che il router trasmette il segnale verso lo switch. RX indica che il router riceve il segnale dallo switch.

3. In alcuni casi, il canale D non viene visualizzato correttamente e rimane nello stato TEI_ASSIGNMENT oppure il livello 2 viene rimbalzato verso l'alto e verso il basso. Il problema potrebbe essere causato da una trasmissione a senso unico o dalla perdita di pacchetti keepalive. Se uno dei due dispositivi non rileva quattro keepalive consecutivi, il rispettivo dispositivo tenta di inizializzare nuovamente il collegamento di layer 2. Per ottenere questo risultato, la parte invierà nuovamente il messaggio SABME e riavvierà il processo. In una situazione di questo tipo, è necessario verificare se i pacchetti keepalive sono effettivamente posizionati sul cavo e se una delle parti non risponde ai pacchetti keepalive quando li riceve.

   Per isolare il problema, usare i comandi debug isdn q921 e show interface serial x:23 sul router e con il provider di servizi T1 (Telco):

   1. Eseguire più volte il comando show interface serial x:23 e verificare che il contatore di output venga incrementato e che non si verifichino errori o perdite di input/output.

   2. Creare un T1 Loopback Plug e quindi collegarlo alla porta T1 per la quale si desidera risolvere il problema. L'output del comando debug isdn q921 deve indicare che SABME è stato inviato e che è stato ricevuto questo messaggio:

      RX <- BAD FRAME(0x00017F)Line may be looped!

      Se non viene visualizzato alcun debug, spegnere e non spegnere il controller T1 corrispondente.

      I messaggi BAD FRAME indicano che il router funziona correttamente. Il router invia il pacchetto SABME. Il messaggio viene rimandato indietro al router, a causa del quale, il router riceve lo stesso messaggio SABME che è stato inviato. Il router lo contrassegna come BAD FRAME e visualizza il messaggio di errore. Il messaggio di errore indica che la linea è probabilmente ripetuta. Questo è il comportamento previsto per il circuito con loop. Pertanto, il problema si trova nello switch Telco ISDN o nel cablaggio tra lo switch Demarc e lo switch Telco.

      Tuttavia, se la linea viene rimandata indietro e il router invia dei SABME ma non li riceve indietro, potrebbe esserci un problema con la spina fisica del loopback dell'hardware o con l'interfaccia del router stessa. Fare riferimento ai test di loopback per le linee T1/56K e verificare se è possibile eseguire il ping del router dallo stesso router con l'aiuto del test di loopback dell'hardware. Se non è possibile eseguire il ping del router, potrebbe essersi verificato un problema hardware con il controller T1. In tal caso, chiamare il TAC per assistenza. Se è possibile eseguire il ping sul router, procedere con il passaggio c.

   3. Dopo aver isolato e testato il router e le porte T1 e averne verificato la correttezza, è necessario rivolgersi alla Telco per ulteriori informazioni sulla risoluzione dei problemi.

      • Contattare la Telco e chiedere perché lo switch non risponde al comando keepalive. Verificare inoltre che Telco visualizzi i messaggi keepalive o qualsiasi messaggio ISDN layer 2 in arrivo inviato dal router.

      • Ripetere il test di loopback, ma questa volta estendere il test di loopback allo switch Telco. Questa procedura è descritta nell'articolo Test di loopback per le linee T1/56K.

      • Chiedere al tecnico dello switch Telco di effettuare un loop sulla linea, quindi verificare se il router è ancora in grado di eseguire il ping da solo.

      • Se il router non è in grado di eseguire il ping tra sé e sé, è possibile che vi sia un problema con il cablaggio del circuito verso lo switch Telco ISDN. per ulteriori informazioni, fare riferimento a Test di loopback per linee T1/56K.

      • Se il router è in grado di eseguire il ping tra se stesso, il test del loopback ha esito positivo. Annullare la configurazione di loopback e modificare la configurazione del controller da channel-group a pri-group.

        maui-nas-03(config)#controller t1 0
        maui-nas-0(config-controller)#no channel-group 0
        maui-nas-0(config-controller)#pri-group timeslots 1-24
        

      • Eseguire l'arresto e non lo spegnimento al controller e verificare se il router invia questo messaggio:

        ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0

        e riceve quanto segue:

        RX <- BAD FRAME(0x00017F)Line may be looped!

        In questo caso, il router funziona correttamente e il percorso di trasmissione e ricezione verso Telco è corretto. Il problema è relativo allo switch ISDN o alla rete ISDN. Tuttavia, se il router invia:

        ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0

        e non riceve:

        RX <- BAD FRAME(0x00017F)Line may be looped!

        Chiama il supporto TAC per ulteriore assistenza.

Risoluzione dei problemi ISDN Layer 3

Per risolvere tutti i problemi di layer 2 associati al PRI e verificare che l'hardware funzioni correttamente, è necessario risolvere il problema relativo al layer 3 ISDN. per ulteriori informazioni, fare riferimento a Risoluzione dei problemi di ISDN BRI layer 3 con il comando debug isdn q931.

Nota: anche se nel documento viene descritta la risoluzione dei problemi del layer 3 per i BRI, è possibile applicare gli stessi concetti alla risoluzione dei problemi del layer 3 PRI. Per interpretare il motivo della disconnessione di layer 3, è inoltre possibile fare riferimento alla sezione Descrizione dei codici della causa di disconnessione isdn q931 di debug.

Informazioni correlate

• Risoluzione dei problemi di allarme T1
• Test di loopback per le linee T1/56K
• Risoluzione dei problemi relativi a T1 Error Events
• Supporto tecnico Cisco e download