Dépannage de T1 PPRI

Introduction

Ce document décrit comment vérifier qu’une interface à débit primaire (PRI) T1 fonctionne correctement.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Lors du dépannage d'un Accès primaire (PRI), assurez-vous que le T1 s'exécute correctement aux deux extrémités. La raison est que la signalisation PRI RNIS s'exécute sur la couche physique de T1. Pour vérifier si la couche 1 de T1 fonctionne correctement, utilisez la commande show controller t1. Assurez-vous qu'il n'y ait aucune erreur sur aucun des compteurs. Assurez-vous que la structure de trame, le codage de lignes et le générateur de signaux d'horloge sont configurés correctement. Référez-vous à l'organigramme de dépannage T1 pour en savoir plus. Communiquez avec votre fournisseur de services pour obtenir la configuration appropriée.

Lorsque vous avez résolu des problèmes dans la couche 1 et que les compteurs show controller t1 sont à zéro, vous pouvez vous concentrer sur les couches 2 et 3 de la signalisation RNIS PRI.

Conseil : vous pouvez utiliser la commande clear counters pour réinitialiser les compteurs T1. Lorsque les compteurs sont dégagés, vous pouvez facilement vérifier si la ligne T1 présente des erreurs. Cependant, n'oubliez pas que cette commande efface également tous les autres compteurs show interface. Voici un exemple :

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

Utiliser la commande show isdn status

La commande show isdn status est très utile pour dépanner les problèmes de signalisation RNIS. La commande show isdn status affiche un résumé de l'état actuel de toutes les interfaces RNIS, ainsi que l'état des couches 1, 2 et 3. Voici un exemple du résultat de la commande 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

Procédez comme suit pour vérifier l'état des couches :

1. Vérifiez si la couche 1 est à l’état ACTIF. L’état de la couche 1 doit toujours être ACTIVE, sauf si la liaison T1 est inactive.

   Si le résultat de la commande show isdn status indique que la couche 1 est DÉSACTIVÉE, il y a un problème avec la connectivité physique de la ligne T1. Si la ligne est administrativement désactivée, utilisez la commande no shutdown pour redémarrer l'interface.

2. Assurez-vous que l'état de la couche 2 est MULTIPLE_FRAME_ESTABLISHED. Il s’agit de l’état requis pour la couche 2. Cet état indique que le routeur a reçu un message RNIS SABME (Set Asynchronous Balanced Mode Extended) et a répondu avec une trame UA (Unnumbered Acknowledge) pour se synchroniser avec le commutateur Telco. En outre, il doit y avoir un échange constant de trames de couche 2 (RR, Receiver Ready) entre les deux périphériques. Dans ce cas, le routeur et le commutateur RNIS ont entièrement initialisé le protocole de couche 2 RNIS. Pour plus d'informations sur l'identification des messages SABME et RR, consultez la section Utiliser la commande debug q921.

   Si la couche 2 n'est pas dans l'état MULTIPLE_FRAME_ESTABLISHED, utilisez la commande debug isdn q921 pour diagnostiquer le problème.

   En outre, la commande show isdn status affiche un résumé de l'état actuel. Par conséquent, la couche 2 peut rebondir vers le haut et vers le bas même si elle indique un état MULTIPLE_FRAME_ESTABLISHED. Utilisez la commande debug isdn q921 pour vous assurer que la couche 2 est stable.

   À ce stade, utilisez la commande show controllers t1 pour vérifier à nouveau le T1 et vous assurer qu'il n'y a pas d'erreurs. En cas d'erreurs, reportez-vous à l'organigramme de dépannage T1.

Dans l'exemple de sortie show isdn status, notez que T1 0 (dont le canal D est Serial 0:23) a la couche 1 comme ACTIVE et la couche 2 comme MULTIPLE_FRAME_ESTABLISHED pour indiquer que le canal de signalisation fonctionne correctement et échange des trames de couche 2 avec le commutateur Telco. Le canal D (Serial1:23) pour T1 1 a la couche 1 ACTIVE, mais la couche 2 est TEI_ASSIGNED, ce qui indique que le PRI n'échange pas de trames de couche 2 avec le commutateur. Utilisez la commande show controller t1 x pour d'abord vérifier le circuit du contrôleur t1, et vérifier s'il est propre (c'est-à-dire qu'il n'a pas d'erreurs) avant de dépanner le problème de couche 2 RNIS avec le debug isdn q921. Référez-vous à l'organigramme de dépannage T1 pour en savoir plus

Utiliser la commande debug isdn q921

Cette commande debug est utile lorsque vous dépannez des problèmes de signalisation de couche 2 RNIS. La commande debug isdn q921 affiche les procédures d'accès de couche liaison de données (couche 2) qui se produisent au niveau du routeur sur le canal D. Cela peut indiquer si le problème provient du NAS, du commutateur Telco ou de la ligne.

Utilisez la commande logging console ou terminal monitor pour vous assurer que vous êtes configuré pour afficher les messages de débogage.

Remarque : dans un environnement de production, utilisez la commande show logging pour vous assurer que la journalisation de la console est désactivée. Si la console de journalisation est activée, le serveur d'accès peut interrompre ses fonctions de façon intermittente lorsque le port de console est surchargé de messages de journalisation. Entrez la commande no logging console pour désactiver la journalisation sur le port de console. Référez-vous à Informations importantes sur les commandes de débogage pour plus d'informations.

Remarque : si debug isdn q921 est activé et que vous ne recevez aucune sortie de débogage, vérifiez d'abord que vous avez activé le moniteur de terminal. Essayez ensuite de réinitialiser le contrôleur ou le canal D pour obtenir les sorties de débogage. Vous pouvez utiliser la commande clear controller t1 ou clear interface serial x:23 pour réinitialiser la ligne.

Suivez ces étapes pour vous assurer que les procédures d'accès à la couche liaison de données ont lieu au niveau du routeur sur le canal D :

1. Vérifiez si la couche 2 est stable. Pour ce faire, recherchez les messages dans la sortie de débogage. Voici la sortie de debug isdn q921 quand le contrôleur T1 passe par un shutdown et no shutdown :

   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

   Si la ligne rebondit vers le haut et vers le bas, un résultat similaire à celui-ci s'affiche :

   %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. Si la couche 2 est stable, le routeur et le commutateur doivent commencer à se synchroniser. Le message Set Asynchronous Balanced Mode Extended (SABME) s'affiche à l'écran. Ce message indique que la couche 2 tente de s'initialiser avec l'autre côté. Chaque côté peut envoyer le message et essayer de s'initialiser avec l'autre côté. Si le routeur reçoit le message SABME, il doit renvoyer une trame d'accusé de réception non numérotée (UAf). Le routeur modifie ensuite l'état de la couche 2 en MULTIPLE_FRAME_ESTABLISHED. Voici un exemple :

   *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
   
   

   Si le commutateur reçoit et reconnaît l’UAf, les deux périphériques se synchronisent et des messages de test d’activité périodiques sont échangés entre le routeur et le commutateur RNIS. Ces messages se présentent sous la forme « Receiver Ready » (RRf et RRp). Ces keepalives sont visibles à dix secondes d'intervalle et permettent de s'assurer que les deux côtés sont capables de communiquer entre eux. Exemple :

   *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
   
   

   

   Remarque : reportez-vous aux sections TX, RX et flèche. TX indique que le routeur transmet le signal vers le commutateur. RX signifie que le routeur reçoit le signal du commutateur.

3. Parfois, le canal D ne s'affiche pas correctement et reste dans l'état TEI_ASSIGNED, ou la couche 2 rebondit de haut en bas. Cela peut être dû à une transmission unidirectionnelle ou à des paquets de test d'activité manqués. Lorsque l'un des deux côtés manque quatre keepalives consécutifs, le côté respectif tente d'initialiser à nouveau la liaison de couche 2. Pour ce faire, la partie réenvoie le message SABME et recommence le processus. Dans une telle situation, vous devez savoir si ces keepalives sont réellement placés sur le câble et si un côté ne répond pas aux keepalives lorsqu'il les reçoit.

   Pour isoler le problème, utilisez les commandes debug isdn q921 et show interface serial x:23 , et complétez ces étapes sur le routeur et avec le fournisseur de services T1 (Telco) :

   1. Exécutez la commande show interface serial x:23 plusieurs fois et assurez-vous que le compteur de sortie s'incrémente et qu'il n'y a pas de pertes ou d'erreurs en entrée/sortie.

   2. Créez une prise de bouclage T1, puis branchez-la sur le port T1 que vous souhaitez dépanner. Le résultat de la commande debug isdn q921 doit indiquer que le SABME a été envoyé et que le message suivant a été reçu :

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

      Si aucun débogage n'apparaît, exécutez les commandes ashutdown et no shutdown sur le contrôleur T1 correspondant.

      Les messages BAD FRAME indiquent que le routeur fonctionne correctement. Le routeur envoie le paquet SABME. Le message est rebouclé sur le routeur, ce qui signifie que le routeur reçoit le même message SABME que celui qui a été envoyé. Le routeur le marque comme étant une TRAME INCORRECTE et présente le message d'erreur. Le message d'erreur indique que la ligne est probablement en boucle. Il s’agit du comportement attendu pour le circuit en boucle. Par conséquent, le problème se situe au niveau du commutateur RNIS Telco ou du câblage entre le point de démarcation et le commutateur Telco.

      Cependant, si la ligne est rebouclée et que le routeur envoie des SABME mais ne les reçoit pas, il peut y avoir un problème avec la prise de bouclage câblée physique ou l'interface du routeur elle-même. Reportez-vous à la section Tests de bouclage pour les lignes T1/56K et vérifiez si vous pouvez envoyer une requête ping au routeur à partir du même routeur à l'aide du test de bouclage de câble. Si vous ne pouvez pas envoyer de requête ping au routeur, il peut y avoir un problème matériel avec le contrôleur T1. Dans ce cas, appelez le TAC pour obtenir de l'aide. Si vous pouvez envoyer une requête ping au routeur, passez à l’étape c.

   3. Après avoir isolé et testé le routeur et les ports T1 et confirmé qu'ils sont corrects, vous devez demander à l'opérateur de télécommunications de poursuivre le dépannage.

      • Contactez l'opérateur téléphonique et demandez-lui pourquoi le commutateur ne répond pas au keepalive. Demandez également à l’opérateur de télécommunications de vérifier s’il voit les messages de test d’activité ou tout message RNIS de couche 2 entrant en provenance du routeur.

      • Effectuez à nouveau le test de bouclage, mais cette fois-ci étendez le test de bouclage au commutateur Telco. Cette procédure est décrite dans l'article Tests de bouclage pour les lignes T1/56K.

      • Demandez au technicien du commutateur Telco de placer une boucle sur la ligne, puis vérifiez si le routeur peut toujours envoyer lui-même une requête ping.

      • Si le routeur ne peut pas envoyer lui-même de requête ping, le câblage du circuit vers le commutateur RNIS Telco peut poser problème. Référez-vous à Tests de bouclage pour les lignes T1/56K pour plus d'informations.

      • Si le routeur peut envoyer lui-même une requête ping, le test de bouclage réussit. Annulez la configuration de bouclage et changez la configuration du contrôleur de channel-group à 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
        

      • Effectuez une mise hors tension et no shutdown sur le contrôleur et vérifiez si le routeur envoie ceci :

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

        et reçoit ceci :

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

        Dans ce cas, le routeur fonctionne correctement et le chemin de transmission et de réception vers Telco est correct. Le problème réside dans le commutateur RNIS ou le réseau RNIS. Toutefois, si le routeur envoie :

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

        et ne reçoit pas ce message :

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

        Appelez l'assistance TAC pour obtenir de l'aide.

Dépannage de la couche 3 RNIS

Lorsque vous résolvez tous les problèmes de couche 2 associés au PRI et que vous confirmez que le matériel fonctionne correctement, vous devez dépanner la couche 3 RNIS. Référez-vous à Dépannage de la couche 3 BRI RNIS avec la commande debug isdn q931 pour plus d'informations.

Remarque : bien que le document traite du dépannage de la couche 3 pour les accès de base, vous pouvez appliquer les mêmes concepts au dépannage PRI de la couche 3. Vous pouvez également vous référer à Comprendre les codes de cause de déconnexion debug isdn q931 pour interpréter la raison de déconnexion de la couche 3.

Informations connexes

• Dépannage de l'alarme T1
• Tests de boucle pour les lignes T1/56K
• Dépannage des erreurs T1
• Assistance technique de Cisco et téléchargements