WAN : T1/E1 et T3/E3

Dépannage de l'accès primaire (PRI) T1

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

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.

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

Conseil : Vous pouvez utiliser les compteurs clairs commandez de remettre à l'état initial les compteurs de t1. Quand les compteurs sont clairs, vous pouvez facilement observer si la ligne de t1 éprouve n'importe quelles erreurs. Cependant, souvenez-vous que cette commande efface tous autres compteurs d'interface d'exposition aussi bien. 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

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Utilisez la commande d'état de show isdn

La commande d'état de show isdn est très utile pour dépanner des problèmes de signalisation RNIS. La commande d'état de show isdn affiche un résumé de l'état actuel de toutes les interfaces RNIS, et également le statut des couches 1, 2, et 3. Voici un exemple de la sortie de commande d'état de show isdn :

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

Terminez-vous ces étapes pour vérifier le statut des couches :

  1. Vérifiez si la couche 1 est dans l'état active. Le statut d'une couche 1 doit toujours être EN ACTIVITÉ à moins que le t1 soit vers le bas.

    Si la sortie de commande d'état de show isdn indique que la couche 1 EST DÉSACTIVÉE, il y a un problème avec la Connectivité physique de la ligne de t1. Si la ligne est administrativement en baisse, n'utilisez l'aucune commande shutdown de redémarrer l'interface.

  2. Assurez-vous que la couche 2 est dans l'état MULTIPLE_FRAME_ESTABLISHED. C'est l'état exigé pour la couche 2. Cet état indique que le routeur a reçu un message RNIS SABME (a placé le mode asynchrone équilibré étendu), et répondu avec une trame uA (non-numéroté reconnaissez) pour synchroniser avec le commutateur de la compagnie de téléphone. En outre, il doit y avoir échange constant de trames de trames de la couche 2 (récepteur prêt, rr) entre les deux périphériques. Quand ceci se produit, le routeur et le commutateur RNIS ont entièrement initialisé le protocole de la couche RNIS 2. Pour les informations sur la façon dont identifier les messages SABME et rr, voyez l'utilisation de la section de commande du débogage q921.

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

    En outre, la commande d'état de show isdn affiche un résumé de l'état actuel. Par conséquent, la couche 2 peut rebondir en haut et en bas quoiqu'elle indique un état MULTIPLE_FRAME_ESTABLISHED. Utilisez la commande de debug isdn q921 de s'assurer que la couche 2 est stable.

    À ce moment, utilisez la commande de show controllers t1 de vérifier le t1 de nouveau, et assurez-vous qu'il n'y a aucune erreur. S'il y a des erreurs, référez-vous au t1 dépannant l'organigramme.

    Dans la sortie d'état de show isdn d'échantillon, notez que ce t1 0 (dont le canal D est l'interface série 0:23) a la couche 1 aussi ACTIVE et posez 2 que MULTIPLE_FRAME_ESTABLISHED pour indiquer que les fonctions de canal de signalisation correctement et les échanges posent 2 trames avec le commutateur de la compagnie de téléphone. Le canal D (Serial1:23) pour le t1 1 a l'ACTIVE de la couche 1, mais la couche 2 est TEI_ASSIGNED, qui indique que le PRI ne permute pas des trames de la couche 2 avec le commutateur. Utilisez le show controller que la commande du t1 X à d'abord vérifient le circuit de controller t1, et le vérifiez s'il est propre (c'est-à-dire, il n'a aucune erreur) avant que vous dépanniez le problème de la couche RNIS 2 avec le debug isdn q921. Référez-vous au t1 dépannant le pour en savoir plus d'organigramme

Utilisez la commande de debug isdn q921

Cette commande de débogage est utile quand vous dépannez des problèmes de signalisation de la couche RNIS 2. La commande de debug isdn q921 affiche la couche liaison de données (les procédures d'accès de couche 2) qui se produisent au routeur sur le canal D. Ceci peut indiquer si le problème se trouve avec le NAS, le commutateur de la compagnie de téléphone ou la ligne.

Utilisez le logging console ou la commande de terminal monitor de vous assurer sont configurées de visualiser des messages de débogage.

Remarque: Dans un environnement de production, utilisez la commande de show logging de s'assurer que la journalisation console est désactivée. Si le logging console est activé, le serveur d'accès peut par intermittence cesser de fonctionner quand le port de console est surchargé avec des messages de log. Sélectionnez la commande de no logging console de désactiver ouvrir une session le port de console. Référez-vous aux informations importantes sur le pour en savoir plus de commandes de debug.

Remarque: Si le debug isdn q921 est activé et vous ne recevez aucune sortie de débogage, premier contrôle et vous veiller pour avoir activé le terminal monitor. Essayez alors de remettre à l'état initial le contrôleur ou le canal D pour obtenir des sorties de débogage. Vous pouvez utiliser le clear controller t1 X ou la commande du clear interface serial x:23 de remettre à l'état initial la ligne.

Terminez-vous ces étapes pour s'assurer que les procédures d'accès à la couche de liaison se produisent au routeur sur le canal D :

  1. Vérifiez si la couche 2 est stable. Pour faire ainsi, recherchez les messages dans la sortie de débogage. Voici le debug isdn q921 sorti quand le contrôleur de t1 passe par un arrêt et aucun arrêt :

    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 en haut et en bas, la sortie semblable à ceci est affichée :

    %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 à synchroniser les uns avec les autres. Le message étendu par mode asynchrone équilibré de positionnement (SABME) apparaît sur l'affichage. Ce message indique que des essais de la couche 2 pour initialiser avec l'autre côté. L'un ou l'autre de côté peut envoyer le message et l'essai pour initialiser avec l'autre côté. Si le routeur reçoit le message SABME, il doit renvoyer un non-numéroté reconnaissent la trame (UAf). Le routeur change alors l'état de la couche 2 à 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 identifie l'UAf, les deux périphériques synchronisent, et le Keepalives périodique est permuté entre le routeur et le commutateur RNIS. Ces messages sont sous forme de récepteur prêt (des forces de réaction rapide et RRP). Ce Keepalives est vu dix secondes à part, et s'assure que les deux côtés peuvent communiquer les uns avec les autres. 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
    
    

    Veuillez noter le TX et le RX et la 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 n'est pas soulevé correctement et reste dans l'état TEI_ASSIGNED, ou pose 2 rebonds en haut et en bas. Ceci pourrait sont provoqué par par une transmission de manière ou paquets keepalive manqués. Quand l'un ou l'autre de côté manque quatre Keepalives consécutifs, les essais latéraux respectifs pour initialiser la couche 2 joignent de nouveau. Pour réaliser ceci, le côté renvoie le message SABME et commence le processus plus de nouveau. Dans une telle situation, vous devez découvrir si ces Keepalives est placé réellement sur le fil et si un côté ne répond pas au Keepalives quand il les reçoit.

    Pour isoler le problème, utiliser le debug isdn q921 et afficher à interface les commandes x:23 séquentielles, et se terminer ces étapes sur le routeur et avec le fournisseur de services de t1 (compagnie de téléphone) :

    1. Exécutez l'interface x:23 séquentiel d'exposition plusieurs fois, et l'assurez que le compteur de sortie incrémente et il n'y a aucune baisse ou erreur d'entrée/sortie.

    2. Créez un connecteur de bouclage de t1 et puis branchez-le au port de t1 que vous voulez dépanner. La sortie de debug isdn q921 doit indiquer que le SABME a été envoyé, et ce message a été reçu :

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

      Si aucun met au point apparaissez, n'exécutez un arrêt et aucun arrêt sur le contrôleur correspondant de t1.

      Les MAUVAIS messages de TRAME indiquent que le routeur est très performant. Le routeur envoie le paquet SABME. Le message est fait une boucle - de retour au routeur, en raison duquel, le routeur reçoit le même message SABME qui a été envoyé. Le routeur le marque comme MAUVAISE TRAME, et présente le message d'erreur. Le message d'erreur déclare que la ligne est probablement faite une boucle. C'est le comportement prévu pour le circuit bouclé. Par conséquent, le problème se trouve en dessous du commutateur RNIS de l'opérateur de téléphonie ou du câblage du point de démarcation au commutateur de la compagnie de téléphone.

      Cependant, si la ligne est faite une boucle - arrière et le routeur envoie SABMEs mais ne les reçoit pas de retour, il peut y a un problème avec l'examen médical câblent le connecteur de bouclage ou l'interface de routeur lui-même. Référez-vous aux tests de bouclage durs de connecteur pour des lignes T1/56K et les vérifiez si vous pouvez cingler le routeur du même routeur avec l'aide du test de bouclage de câblage. Si vous ne pouvez pas cingler le routeur, il peut y a un problème matériel avec le contrôleur de t1. En pareil cas, appelez le TAC pour l'assistance. Si vous pouvez cingler le routeur, passez à l'étape le C.

    3. Après que vous ayez isolé et testé le routeur et le t1 met en communication et a confirmé qu'ils sont bons, vous devez engager la compagnie de téléphone pour dépanner plus loin.

      • Entrez en contact avec la compagnie de téléphone et enquérez-vous quant à pourquoi le commutateur ne répond pas à la keepalive. Ayez également le contrôle de compagnie de téléphone pour voir s'ils voient les messages de keepalive ou n'importe quel message de la couche 2 de RNIS entrant du routeur.

      • Réalisez le test de bouclage de nouveau, mais cette fois étendent le test de bouclage au commutateur de la compagnie de téléphone. Cette procédure est décrite dans les tests de bouclage durs de connecteur pour des lignes document T1/56K.

      • Demandez au technicien de commutateur de la compagnie de téléphone de placer une boucle sur la ligne, et puis testez si le routeur peut encore se cingler.

      • Si le routeur ne peut pas se cingler, il peut y a un problème avec le câblage du circuit vers le commutateur RNIS de l'opérateur de téléphonie. Référez-vous aux tests de bouclage durs de connecteur pour des lignes pour en savoir plus T1/56K.

      • Si le routeur peut se cingler, le test de bouclage est réussi. Annulez la configuration de bouclage et changez la configuration de contrôleur du channel-group au 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
        
      • N'exécutez un arrêt et aucun arrêt au contrôleur et au contrôle pour voir 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!

        Si ceci se produit, les fonctions routeur correctement et la transmission et le chemin reçu vers la compagnie de téléphone est bien. Le problème s'étend dans le commutateur RNIS ou le réseau RNIS. Cependant, si le routeur envoie :

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

        et ne reçoit pas ceci :

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

        veuillez appeler le TAC pour davantage d'assistance.

Dépannez plus loin

Quand vous résolvez tous les problèmes de la couche 2 associés avec le PRI, et les confirmez que le matériel fonctionne bien, vous devez dépanner la couche RNIS 3. vous rapportez dépannage derrière la couche 3 RNIS BRI utilisant le pour en savoir plus de commande de debug isdn q931.

Remarque: Quoique le document discute le dépannage de la couche 3 pour BRIs, vous pouvez appliquer les mêmes concepts pour poser le dépannage PRI 3. Vous pouvez également se référer compréhension derrière codes de motif de déconnexion de debug isdn q931 pour interpréter la raison de débranchement de la couche 3.


Informations connexes


Document ID: 8131