Dépannage des problèmes de ligne série

Introduction

Ce chapitre présente l'information générale de dépannage et une discussion des techniques et outils pour le dépannage des connexions série. Le chapitre comprend les sections suivantes :

• Dépannage à l'aide de la commande show interfaces serial

• Utilisation de la commande show controllers

• Utilisation des commandes debug

• Utilisation de tests ping étendus

• Dépannage des problèmes de synchronisation

• Réglage des tampons

• Tests de ligne série spéciaux

• Informations détaillées sur la commande show interfaces serial

• Dépannage des problèmes T1

• Dépannage des problèmes E1

Conditions préalables

Conditions requises

Les lecteurs de ce document doivent connaître les définitions suivantes.

• DTE = data terminal equipment ou équipement pour terminal de données

• CD = Détection de porteuse

• CSU = unité de service de canal

• DSU = unité de service numérique

• SCTE = horloge de transmission série externe

• DCE = équipement de terminaison de circuit de données

• CTS = clear-to-send

• DSR = prêt pour le jeu de données

• SAP = Service Advertising Protocol

• IPX = Internetwork Packet Exchange

• FDDI = interface de données distribuées à fibre optique

• ESF = Extended Superframe Format

• B8ZS = substitution binaire à huit zéros

• LBO = Elargissement de ligne

Components Used

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

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Dépannage à l’aide de la commande show interfaces serial

Le résultat de la commande EXEC show interfaces serial affiche des informations spécifiques aux interfaces série. La Figure 15-1 présente le résultat de la commande EXEC show interfaces serial pour une interface série HDLC (High-Level Data Link Control).

Cette section décrit comment utiliser la commande show interfaces serial pour diagnostiquer les problèmes de connectivité de ligne série dans un environnement de réseau étendu (WAN). Les sections suivantes décrivent certains des champs importants de la sortie de commande.

Les autres champs affichés dans l'écran sont décrits en détail dans la section « Informations détaillées sur la commande show interfaces serial« , plus loin dans ce chapitre.

Lignes série: show interfaces serial Status Line Conditions

Vous pouvez identifier cinq états de problème possibles dans la ligne d'état de l'interface de l'affichage show interfaces serial (voir Figure 15-1) :

• L’interface série x est désactivée, le protocole de ligne est désactivé

• Serial x activé, protocole de ligne désactivé

• Série x activée, protocole de ligne activé (en boucle)

• Série x activée, protocole de ligne désactivé

• L’interface série x est désactivée sur le plan administratif, le protocole de ligne est désactivé

Figure 15-1 Sortie de la commande show interface serial HDLC

Tableau 15-1 : Lignes série: show interfaces serial Status Line Conditions - Ce tableau présente les conditions d'état de l'interface, les problèmes éventuels associés aux conditions et les solutions à ces problèmes.

Condition de ligne d'état	Problème possible	Solution
Serial x activé, protocole de ligne activé		Il s'agit de la condition de ligne d'état appropriée. Aucune action requise.
L’interface série x est désactivée, le protocole de ligne est désactivé (mode ETTD)	Indique généralement que le routeur ne détecte pas de signal CD (c'est-à-dire que le CD n'est pas actif). Problème de la compagnie de téléphone La ligne est en panne ou la ligne n'est pas connectée à l'unité CSU/DSU Câblage défectueux ou incorrect Panne matérielle (CSU/DSU)	Vérifiez les DEL de l'unité CSU/DSU pour voir si le CD est actif ou insérez une case de séparation sur la ligne pour vérifier le signal du CD. Vérifiez que vous utilisez le câble et l'interface appropriés (reportez-vous à la documentation relative à l'installation du matériel). Insérez une case de séparation et cochez toutes les pistes de contrôle. Contactez votre ligne louée ou tout autre service de l'opérateur pour voir s'il y a un problème. Remplacez les pièces défectueuses. Si vous soupçonnez une défaillance matérielle du routeur, remplacez la ligne série par un autre port. Si la connexion s'active, l'interface précédemment connectée présente un problème.
Serial x is up, line protocol is down (mode ETTD)	Le routeur local ou distant n’est pas configuré correctement Les keepalives ne sont pas envoyés par un routeur distant Problème lié à la ligne louée ou à un autre service de l'opérateur - Ligne bruyante, ou commutateur mal configuré ou défaillant Problème de synchronisation sur le câble (SCTE non défini sur CSU/DSU) Échec de l'unité CSU/DSU locale ou distante CSU/DSU local ou distant en panne Panne matérielle du routeur (locale ou distante)	Placez le modem, l’unité CSU ou l’unité DSU en mode de bouclage local et utilisez la commande show interfaces serial pour voir si le protocole de ligne s’active. Si le protocole de ligne apparaît, un problème de compagnie de téléphone ou un routeur distant défaillant est le problème probable. Si le problème semble se trouver à l'extrémité distante, répétez l'étape 1 sur le modem distant, l'unité CSU ou l'unité DSU. Vérifiez tous les câbles. Assurez-vous que le câble est connecté à l’interface appropriée, à l’unité CSU/DSU appropriée et au point de terminaison du réseau de la compagnie de téléphone approprié. Utilisez la commande EXEC show controllers pour déterminer quel câble est connecté à quelle interface. Activez la commande EXEC debug serial interface. Attention : Comme la sortie de débogage se voit attribuer une priorité élevée dans le processus du processeur, elle peut rendre le système inutilisable. Pour cette raison, utilisez les commandes debug uniquement pour résoudre des problèmes spécifiques ou lors de sessions de dépannage avec le personnel d'assistance technique de Cisco. En outre, il est préférable d'utiliser les commandes debug pendant les périodes de faible trafic réseau et de moins d'utilisateurs. Le débogage au cours de ces périodes réduit la probabilité que l'augmentation de la surcharge de traitement des commandes debug affecte l'utilisation du système. Si le protocole de ligne ne s'active pas en mode de bouclage local et si le résultat de la commande EXEC debug serial interface indique que le compteur keepalive n'est pas incrémenté, un problème matériel de routeur est probable. Échangez le matériel de l’interface du routeur. Si le protocole de ligne s'active et que le compteur keepalive s'incrémente, le problème n'est pas dans le routeur local. Dépannez la ligne série comme décrit dans les sections Dépannage des problèmes de synchronisation et Tests de bouclage CSU et DSU, plus loin dans ce chapitre. Si vous soupçonnez une défaillance matérielle du routeur, remplacez la ligne série par un port inutilisé. Si la connexion s'active, l'interface précédemment connectée présente un problème.
Serial x is up, line protocol is down (mode DCE)	Commande de configuration d'interface clockrate manquante Le périphérique ETTD ne prend pas en charge ou n'est pas configuré pour le mode SCTE CSU ou DSU distant en panne Câble défectueux ou incorrect Panne matérielle du routeur	Ajoutez la commande de configuration d'interface clockrate sur l'interface série. Syntaxe: Syntaxe de fréquence d'horloge bps Description : fréquence d'horloge souhaitée bps en bits par seconde : 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148 000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 400000, 8, 000000. Réglez le périphérique ETTD sur le mode SCTE si possible. Si votre unité CSU/DSU ne prend pas en charge SCTE, vous devrez peut-être désactiver SCTE sur l'interface du routeur Cisco. Reportez-vous à la section Inverting the Transmit Clock, plus loin dans ce chapitre. Vérifiez que le câble approprié est utilisé. Si le protocole de ligne est toujours inactif, il peut y avoir une défaillance matérielle ou un problème de câblage. Insérez une boîte de dérivation et observez les pistes. Remplacer les pièces défectueuses si nécessaire.
Série x activée, protocole de ligne activé (en boucle)	Il existe une boucle dans le circuit. Le numéro de séquence du paquet keepalive devient un numéro aléatoire lorsqu'une boucle est détectée initialement. Si le même nombre aléatoire est retourné sur la liaison, il existe une boucle.	Utilisez la commande show running-config en mode d’exécution privilégié pour rechercher les entrées de commande de configuration d’interface de bouclage. Si vous trouvez une entrée de commande de configuration d'interface de bouclage, utilisez la commande de configuration d'interface no loopback pour supprimer la boucle. Si vous ne trouvez pas la commande de configuration d'interface de bouclage, examinez l'unité CSU/DSU pour voir si elles sont configurées en mode de bouclage manuel. Si tel est le cas, désactivez le bouclage manuel. Réinitialisez l'unité CSU ou DSU et vérifiez l'état de la ligne. Si le protocole de ligne apparaît, aucune autre action n’est nécessaire. Si l'unité CSU ou DSU n'est pas configurée en mode bouclage manuel, contactez le service de ligne louée ou tout autre service d'opérateur pour obtenir de l'aide en matière de dépannage de ligne.
Série x activée, protocole de ligne désactivé	Taux d'erreur élevé en raison d'un problème de service de la compagnie de téléphone Problème matériel CSU ou DSU Matériel de routeur incorrect (interface)	Dépannez la ligne à l'aide d'un analyseur série et d'une boîte de dérivation. Recherchez les signaux CTS et DSR basculants. Boucle CSU/DSU (boucle ETTD). Si le problème persiste, il est probable qu'il y ait un problème matériel. Si le problème ne persiste pas, il est probable qu'il y ait un problème de compagnie de téléphone. Remplacez le matériel défectueux selon les besoins (CSU, DSU, commutateur, routeur local ou distant).
L’interface série x est désactivée sur le plan administratif, le protocole de ligne est désactivé	La configuration du routeur inclut la commande de configuration d'interface shutdown. Adresse IP dupliquée	Vérifiez la configuration du routeur pour la commande shutdown. Utilisez la commande de configuration d'interface no shutdown pour supprimer la commande shutdown. Vérifiez qu'il n'existe aucune adresse IP identique à l'aide de la commande d'exécution privilégiée show running-config ou de la commande d'exécution show interfaces. S'il existe des adresses en double, résolvez le conflit en modifiant l'une des adresses IP.

Lignes série: Augmentation des pertes de sortie sur la liaison série

Les pertes de sortie apparaissent dans le résultat de la commande show interfaces serial (voir Figure 15-1) lorsque le système tente de transférer un paquet à une mémoire tampon de transmission, mais qu'aucune mémoire tampon n'est disponible.

Symptôme : Un nombre croissant de pertes de sortie sur la liaison série.

Tableau 15-2 Lignes série : Augmenter les pertes de sortie sur la liaison série - Ce tableau présente les problèmes possibles qui peuvent provoquer ce symptôme et suggère des solutions.

Problème possible

Solution

Le débit d’entrée de l’interface série dépasse la bande passante disponible sur la liaison série

Minimiser le trafic de diffusion périodique (par exemple, le routage et les mises à jour SAP) à l’aide de listes d’accès ou par d’autres moyens. Par exemple, pour augmenter le délai entre les mises à jour SAP, utilisez la commande de configuration d'interface ipx sap-interval. Augmentez la taille de la file d'attente de mise en attente de sortie par petits incréments (par exemple, 25 %), à l'aide de la commande de configuration d'interface hold-queue out. Sur les interfaces affectées, désactivez la commutation rapide pour les protocoles très utilisés. Par exemple, pour désactiver la commutation IP rapide, entrez la commande de configuration d'interface no ip route-cache. Pour obtenir la syntaxe des commandes pour les autres protocoles, consultez les guides de configuration et les références des commandes de Cisco IOS. Implémentez la mise en file d’attente par priorité sur les liaisons série plus lentes en configurant les listes de priorité. Pour plus d'informations sur la configuration des listes de priorités, reportez-vous aux guides de configuration et aux références des commandes de Cisco IOS. Note : Les pertes de sortie sont acceptables dans certaines conditions. Par exemple, si une liaison est surexploitée (sans aucun moyen de remédier à la situation), il est souvent préférable de supprimer des paquets plutôt que de les conserver. Ceci est vrai pour les protocoles qui prennent en charge le contrôle de flux et peuvent retransmettre des données (telles que TCP/IP et Novell IPX). Cependant, certains protocoles, tels que DECnet et le transport local, sont sensibles aux paquets abandonnés et prennent en charge la retransmission de manière inadéquate, voire inadéquate.

Lignes série: Augmentation des pertes d'entrée sur la liaison série

Les pertes d'entrée apparaissent dans le résultat de la commande show interfaces serial EXEC (voir Figure 15-1) lorsque trop de paquets de cette interface sont toujours traités dans le système.

Symptôme : Un nombre croissant de pertes d'entrée sur la liaison série.

Tableau 15-3 : Lignes série: Augmenter les pertes d'entrée sur la liaison série - Ce tableau présente les problèmes possibles qui peuvent provoquer ce symptôme et suggère des solutions.

Problème possible

Solution

Le débit d'entrée dépasse la capacité du routeur ou les files d'attente d'entrée dépassent la taille des files d'attente de sortie

Remarque : Les problèmes de perte d'entrée sont généralement observés lorsque le trafic est acheminé entre des interfaces plus rapides (Ethernet, Token Ring et FDDI, par exemple) et des interfaces série. Lorsque le trafic est léger, il n'y a aucun problème. À mesure que le trafic augmente, les sauvegardes commencent à se produire. Les routeurs abandonnent les paquets pendant ces périodes encombrées. Augmentez la taille de la file d'attente de sortie sur les interfaces de destination communes pour l'interface qui abandonne les paquets. Utilisez la commande de configuration d'interface hold-queue out. Augmentez ces files d'attente par petits incréments (par exemple, 25 %) jusqu'à ce que vous ne voyiez plus de pertes dans la sortie show interfaces. La limite de la file d'attente de sortie par défaut est de 100 paquets. Réduisez la taille de la file d'attente d'entrée, à l'aide de la commande de configuration d'interface hold-queue, pour forcer les pertes d'entrée à devenir des pertes de sortie. Les pertes de sortie ont moins d'impact sur les performances du routeur que les pertes d'entrée. La file d'attente d'entrée par défaut est de 75 paquets.

Lignes série: Augmentation des erreurs d'entrée supérieures à un pour cent du trafic d'interface total

Si des erreurs d'entrée apparaissent dans la sortie show interfaces serial (voir Figure 15-1), il existe plusieurs sources possibles de ces erreurs. Les sources les plus probables sont résumées au tableau 15-4.

Remarque : toute valeur d'erreur d'entrée pour les erreurs CRC (Cycles Redundancy Check), les erreurs de tramage ou l'abandon supérieur à 1 % du trafic total de l'interface suggère un type de problème de liaison qui doit être isolé et réparé.

Symptôme : Un nombre croissant d'erreurs d'entrée dépassant 1 % du trafic total de l'interface.

Tableau 15-4 : Lignes série: Augmentation des erreurs d'entrée supérieures à un pour cent du trafic d'interface total

Problème possible

Solution

Les problèmes suivants peuvent entraîner ce symptôme : Équipement défectueux de la compagnie de téléphone Ligne série bruyante Configuration de synchronisation incorrecte (SCTE non défini) Câble ou câble incorrect trop long Câble ou connexion défectueux CSU ou DSU défectueux Matériel de routeur incorrect Convertisseur de données ou autre périphérique utilisé entre le routeur et la DSU

Remarque : Cisco recommande vivement de ne pas utiliser de convertisseurs de données lorsque vous connectez un routeur à un réseau WAN ou série. Utilisez un analyseur série pour isoler la source des erreurs d'entrée. Si vous détectez des erreurs, il est probable qu'il y ait un problème matériel ou une incompatibilité d'horloge dans un périphérique externe au routeur. Utilisez les tests de bouclage et ping pour isoler la source du problème spécifique. Pour plus d'informations, reportez-vous aux sections « Using the trace Command » et « CSU and DSU Loopback Tests », plus loin dans ce chapitre. Recherchez des motifs. Par exemple, si des erreurs se produisent à un intervalle cohérent, elles peuvent être liées à une fonction périodique telle que l’envoi de mises à jour de routage.

Lignes série: Dépannage des erreurs d'entrée de ligne série

Tableau 15-5 : Ce tableau décrit les différents types d'erreurs d'entrée affichés par la commande show interfaces serial (voir Figure 15-1), les problèmes possibles qui peuvent être à l'origine des erreurs et les solutions à ces problèmes.

Type d'erreur d'entrée (Nom du champ)	Problème possible	Solution
Erreurs CRC (CRC)	Des erreurs CRC se produisent lorsque le calcul CRC n'est pas transmis, ce qui indique que les données sont corrompues, pour l'une des raisons suivantes : Ligne série bruyante Le câble série est trop long ou le câble entre l’unité CSU/DSU et le routeur n’est pas blindé Le mode SCTE n'est pas activé sur DSU L'horloge de ligne CSU n'est pas configurée correctement Problème de densité sur la liaison T1 (spécification de tramage ou de codage incorrecte)	Assurez-vous que la ligne est suffisamment propre pour répondre aux besoins de transmission. Boucler le câble si nécessaire. Assurez-vous que le câble est dans la longueur recommandée (pas plus de 15,24 mètres) ou 7,62 mètres) pour la liaison T1. Assurez-vous que tous les périphériques sont correctement configurés pour une horloge de ligne commune. Définissez SCTE sur la DSU locale et distante. Si votre unité CSU/DSU ne prend pas en charge SCTE, reportez-vous à la section Inverting the Transmit Clock, plus loin dans ce chapitre. Assurez-vous que l’unité CSU/DSU locale et distante est configurée pour le même schéma de tramage et de codage que celui utilisé par la ligne louée ou par un autre service de l’opérateur (par exemple, ESF/B8ZS). Contactez votre ligne louée ou un autre service de transporteur et demandez-lui d'effectuer des tests d'intégrité sur la ligne.
Erreurs de trame (trame)	Une erreur de tramage se produit lorsqu’un paquet ne se termine pas sur une limite d’octets de 8 bits pour l’une des raisons suivantes : Ligne série bruyante Câble mal conçu ; le câble série est trop long ; Le câble entre l’unité CSU ou DSU et le routeur n’est pas blindé Le mode SCTE n'est pas activé sur la DSU ; l'horloge de la ligne CSU n'est pas correctement configurée ; une des horloges est configurée pour l'horloge locale Problème de densité sur la liaison T1 (spécification de tramage ou de codage incorrecte)	Assurez-vous que la ligne est suffisamment propre pour répondre aux besoins de transmission. Boucler le câble si nécessaire. Vérifiez que vous utilisez le câble approprié. Assurez-vous que le câble est dans la longueur recommandée (pas plus de 15,24 mètres) ou 7,62 mètres) pour la liaison T1. Assurez-vous que tous les périphériques sont correctement configurés pour utiliser une horloge de ligne commune. Définissez SCTE sur la DSU locale et distante. Si votre unité CSU/DSU ne prend pas en charge SCTE, reportez-vous à la section Inverting the Transmit Clock (Inverting the Transmit Clock) plus loin dans ce chapitre. Assurez-vous que l’unité CSU/DSU locale et distante est configurée pour le même schéma de tramage et de codage que celui utilisé par la ligne louée ou par un autre service de l’opérateur (par exemple, ESF/B8ZS). Contactez votre ligne louée ou un autre service de transporteur et demandez-lui d'effectuer des tests d'intégrité sur la ligne.
Transmission abandonnée (abandon)	Les abandons indiquent une séquence illégale d’un bit (plus de sept bits d’une ligne). Les raisons possibles de cette occurrence sont les suivantes : Le mode SCTE n'est pas activé sur DSU L'horloge de ligne CSU n'est pas configurée correctement Le câble série est trop long ou le câble entre l’unité CSU ou DSU et le routeur n’est pas blindé Problème de densité sur la liaison T1 (spécification de tramage ou de codage incorrecte) Paquet terminé au milieu de la transmission, généralement en raison d’une réinitialisation de l’interface ou d’une erreur de trame Problème matériel : circuit défectueux, CSU/DSU défectueux ou interface d’envoi défectueuse sur un routeur distant	Assurez-vous que tous les périphériques sont correctement configurés pour utiliser une horloge de ligne commune. Définissez SCTE sur la DSU locale et distante. Si votre unité CSU/DSU ne prend pas en charge SCTE, reportez-vous à la section Inverting the Transmit Clock, plus loin dans ce chapitre. Boucler le câble si nécessaire. Assurez-vous que le câble est dans la longueur recommandée (pas plus de 15,24 mètres) ou 7,62 mètres) pour la liaison T1. Assurez-vous que toutes les connexions sont bonnes. Vérifiez le matériel aux deux extrémités de la liaison. Remplacez le matériel défectueux si nécessaire. Débits de données réduits et voir si les abandons diminuent. Utilisez des tests de bouclage locaux et distants pour déterminer où se produisent les abandons. Reportez-vous à la section « Special Serial Line Tests », plus loin dans ce chapitre. Contactez votre ligne louée ou un autre service de transporteur et demandez-lui d'effectuer des tests d'intégrité sur la ligne.

Lignes série: Augmentation des réinitialisations d'interface sur la liaison série

Les réinitialisations d'interface qui apparaissent dans le résultat de la commande show interfaces serial EXEC (voir Figure 15-1) sont le résultat de paquets de conservation d'activité manqués.

Symptôme : Un nombre croissant de réinitialisations d’interface sur la liaison série.

Tableau 15-6 : Ce tableau présente les problèmes qui peuvent causer ce symptôme et propose des solutions.

Problème possible

Solution

Les problèmes suivants peuvent entraîner ce symptôme : Congestion sur la liaison (généralement associée aux pertes de sortie) Une mauvaise ligne cause des transitions de CD Problème matériel éventuel au niveau de l’unité CSU, de l’unité DSU ou du commutateur

Lorsque des réinitialisations d’interface se produisent, examinez d’autres champs de la sortie de la commande show interfaces serial pour déterminer la source du problème. En supposant qu'une augmentation des réinitialisations d'interface est enregistrée, examinez les champs suivants : S'il y a un nombre élevé de pertes de sortie dans la sortie show interfaces serial, voir la section « Lignes série : Augmenter les pertes de sortie sur la liaison série », plus haut dans ce chapitre. Vérifiez le champ Carrier transitions dans l'affichage show interfaces serial. Si les transitions de porteuse sont élevées pendant que les réinitialisations d'interface sont enregistrées, le problème est susceptible d'être une mauvaise liaison ou une CSU ou DSU défectueuse. Contactez votre service de ligne louée ou de transporteur et échangez les équipements défectueux si nécessaire. Examinez le champ d'erreurs d'entrée dans l'affichage show interfaces serial. Si les erreurs d'entrée sont élevées alors que les réinitialisations d'interface augmentent, le problème est probablement une liaison défectueuse ou une unité CSU/DSU défectueuse. Contactez votre ligne louée ou tout autre service de l'opérateur et échangez les équipements défectueux si nécessaire.

Lignes série: L'augmentation des transitions de porteuse dépend de la liaison série

Les transitions de porteuse apparaissent dans la sortie de la commande EXEC show interfaces serial chaque fois qu'il y a une interruption dans le signal de porteuse (comme une réinitialisation d'interface à l'extrémité distante d'une liaison).

Symptôme : Un nombre croissant de transitions de porteuse dépendent de la liaison série.

Le tableau 15-7 présente les problèmes qui peuvent causer ce symptôme et propose des solutions.

Tableau 15-7 : Lignes série: L'augmentation des transitions de porteuse dépend de la liaison série

Problème possible	Solution
Les problèmes suivants peuvent entraîner ce symptôme : Interruptions de ligne dues à une source externe (comme la séparation physique du câblage, les alarmes T1 rouges ou jaunes ou la foudre frappant quelque part le long du réseau) Commutateur, DSU ou matériel de routeur défectueux	Vérifiez le matériel aux deux extrémités de la liaison. Fixez une boîte de dérivation ou un analyseur série et testez-la pour déterminer la source des problèmes. Si un analyseur ou une boîte de dérivation ne parvient pas à identifier de problèmes externes, vérifiez le matériel du routeur. Remplacez le matériel défectueux si nécessaire.

Utilisation de la commande show controllers

La commande EXEC show controllers est un autre outil de diagnostic important lors du dépannage des lignes série. La syntaxe des commandes varie selon la plate-forme :

• Pour les interfaces série sur les routeurs de la gamme Cisco 7000, utilisez la commande EXEC show controllers cbus.

• Pour les produits d'accès Cisco, utilisez la commande EXEC show controllers.

• Pour AGS, CGS et MGS, utilisez la commande EXEC show controllers mci.

La Figure 15-2 présente le résultat de la commande EXEC show controllers cbus. Cette commande est utilisée sur les routeurs de la gamme Cisco 7000 avec la carte FSIP (Fast Serial Interface Processor). Vérifiez le résultat de la commande pour vous assurer que le câble vers l’unité CSU/DSU (Channel Service Unit/Digital Service Unit) est connecté à l’interface appropriée. Vous pouvez également vérifier la version du microcode pour voir s'il est à jour.

Figure 15-2 : Sortie de commande show controllers cbus

Sur les produits d'accès tels que les serveurs et routeurs d'accès des gammes Cisco 2000, Cisco 2500, Cisco 3000 et Cisco 4000, utilisez la commande EXEC show controllers. La Figure 15-3 présente la sortie de la commande show controllers de l'interface BRI (Basic Rate Interface) et des interfaces série sur un serveur d'accès Cisco 2503. (Notez que certains résultats ne sont pas affichés.)

La sortie show controllers indique l'état des canaux d'interface et si un câble est connecté à l'interface. Dans la Figure 15-3, un câble ETTD RS-232 est connecté à l'interface série 0. L’interface série 1 ne comporte aucun câble.

La Figure 15-4 présente le résultat de la commande show controllers mci. Cette commande est utilisée uniquement sur les routeurs AGS, CGS et MGS. Si l'interface électrique est affichée comme INCONNUE (au lieu de V.35, EIA/TIA-449 ou d'un autre type d'interface électrique), un câble mal connecté est le problème probable. Une mauvaise application ou un problème avec le câblage interne de la carte est également possible. Si l'interface électrique est inconnue, l'affichage correspondant à la commande EXEC show interfaces serial indique que l'interface et le protocole de ligne sont désactivés.

Figure 15-3 : Sortie de commande show controllers

Figure 15-4 : Sortie de la commande show controllers mci

Utilisation des commandes debug

Le résultat des différentes commandes debug en mode d’exécution privilégié fournit des informations de diagnostic relatives à l’état du protocole et à l’activité du réseau pour de nombreux événements d’interconnexion de réseaux.

Attention : Comme la sortie de débogage se voit attribuer une priorité élevée dans le processus du processeur, elle peut rendre le système inutilisable. Pour cette raison, utilisez les commandes debug uniquement pour résoudre des problèmes spécifiques ou lors de sessions de dépannage avec le personnel d'assistance technique de Cisco. En outre, il est préférable d'utiliser les commandes debug pendant les périodes de faible trafic réseau et de moins d'utilisateurs. Le débogage au cours de ces périodes réduit la probabilité que l'augmentation de la surcharge de traitement des commandes debug affecte l'utilisation du système. Lorsque vous avez fini d'utiliser une commande debug, n'oubliez pas de la désactiver avec sa commande spécifique no debug ou avec la commande no debug all.

Les commandes de débogage suivantes sont utiles lors du dépannage de problèmes de série et de réseau étendu. Pour plus d'informations sur la fonction et la sortie de chacune de ces commandes, consultez la publication Debug Command Reference :

• debug serial interface - Vérifie si les paquets de keepalive HDLC sont incrémentés. Dans le cas contraire, un problème de synchronisation peut se produire sur la carte d’interface ou sur le réseau.

• debug x25 events - Détecte les événements X.25, tels que l'ouverture et la fermeture des circuits virtuels commutés (SVC). Les informations de cause et de diagnostic qui en résultent sont incluses dans le rapport d'événement.

• debug lapb - Informations LAPB ou X.25 de niveau 2 pour la procédure d'accès aux liaisons de sortie.

• debug arp - Indique si le routeur envoie des informations sur les routeurs (avec des paquets ARP) ou en apprend sur eux de l'autre côté du nuage WAN. Utilisez cette commande lorsque certains noeuds d'un réseau TCP/IP répondent, mais que d'autres ne répondent pas.

• debug frame-relay lmi - Obtient des informations LMI (Local Management Interface) utiles pour déterminer si un commutateur Frame Relay et un routeur envoient et reçoivent des paquets LMI.

• debug frame-relay events - Détermine si des échanges se produisent entre un routeur et un commutateur Frame Relay.

• debug ppp negotiation - Affiche les paquets PPP (Point-to-Point Protocol) transmis au démarrage du protocole PPP, où les options PPP sont négociées.

• debug ppp packet - Affiche les paquets PPP envoyés et reçus. Cette commande affiche les vidages de paquets de bas niveau.

• debug ppp errors - Affiche les erreurs PPP (telles que les trames illégales ou mal formées) associées à la négociation et au fonctionnement de la connexion PPP.

• debug ppp chap - Affiche les échanges de paquets CHAP (PPP Challenge Handshake Authentication Protocol) et PAP (Password Authentication Protocol).

• debug serial packet - Affiche les paquets SMDS (Switched Multimegabit Data Service) envoyés et reçus. Cet affichage imprime également les messages d'erreur pour indiquer pourquoi un paquet n'a pas été envoyé ou reçu par erreur. Pour SMDS, la commande vide l'en-tête SMDS entier et certaines données utiles lorsqu'un paquet SMDS est transmis ou reçu.

Utilisation des tests ping étendus

La commande ping constitue un test utile pour les périphériques d'interconnexion de réseaux Cisco, ainsi que pour de nombreux systèmes hôtes. Dans TCP/IP, cet outil de diagnostic est également appelé requête d'écho ICMP (Internet Control Message Protocol).

Remarque : La commande ping est particulièrement utile lorsque des niveaux élevés d'erreurs d'entrée sont enregistrés dans l'affichage show interfaces serial. Voir la Figure 15-1 .

Les périphériques d’interconnexion de réseaux Cisco fournissent un mécanisme permettant d’automatiser l’envoi de nombreux paquets ping dans l’ordre. La figure 15-5 illustre le menu utilisé pour spécifier les options ping étendues. Cet exemple spécifie 20 requêtes ping successives. Cependant, lors du test des composants de votre ligne série, vous devez spécifier un nombre beaucoup plus grand, par exemple 1 000 requêtes ping.

Figure 15-5 : Menu Spécification ping étendue

Exécution de tests ping

En règle générale, exécutez les tests ping de ligne série comme suit :

1. Mettez l’unité CSU ou DSU en mode de bouclage local.

2. Configurez la commande ping étendue pour envoyer différents modèles de données et tailles de paquets. La figure 15-6 et la figure 15-7 illustrent deux tests ping utiles, un ping à tous les zéros (1500 octets) et un ping à tous les uns (1500 octets), respectivement.

3. Examinez le résultat de la commande show interfaces serial (voir Figure 15-1) et déterminez si les erreurs d'entrée ont augmenté. Si le nombre d'erreurs en entrée n'a pas augmenté, le matériel local (DSU, câble, carte d'interface du routeur) est probablement en bon état.

   En supposant que cette séquence de test a été provoquée par l'apparition d'un grand nombre d'erreurs CRC et de tramage, un problème d'horloge est probable. Recherchez un problème de synchronisation dans l’unité CSU ou DSU. Reportez-vous à la section Dépannage des problèmes de synchronisation, plus loin dans ce chapitre.

4. Si vous déterminez que la configuration de synchronisation est correcte et fonctionne correctement, mettez l’unité CSU ou DSU en mode de bouclage à distance.

5. Répétez le test ping et recherchez des modifications dans les statistiques d'erreur d'entrée.

6. Si les erreurs d'entrée augmentent, il y a un problème dans la ligne série ou sur l'unité CSU/DSU. Contactez le fournisseur de services WAN et échangez l'unité CSU ou DSU. Si des problèmes persistent, contactez votre représentant du support technique.

Figure 15-6 : Test ping ALl-Zeros 1 500 octets

Figure 15-7 Test ping 1 500 octets pour tous

Dépannage des problèmes de synchronisation

Les conflits de synchronisation dans les connexions série peuvent entraîner une perte chronique du service de connexion ou une dégradation des performances. Cette section traite des aspects importants des problèmes de synchronisation : causes des problèmes de synchronisation, détection des problèmes de synchronisation, isolation des problèmes de synchronisation et solutions aux problèmes de synchronisation.

Présentation de la synchronisation

L’unité CSU/DSU déduit l’horloge des données qui la traversent. Pour récupérer l'horloge, le matériel CSU/DSU doit recevoir au moins une valeur 1 bit pour chaque 8 bits de données qui le traversent ; c'est ce qu'on appelle la densité des ones. La gestion de la densité des uns permet au matériel de récupérer l'horloge des données de manière fiable.

Les mises en oeuvre T1 récentes utilisent généralement le tramage ESF (Extended Superframe Format) avec codage binaire de substitution à huit zéros (B8ZS). B8ZS fournit un schéma par lequel un code spécial est remplacé chaque fois que huit zéros consécutifs sont envoyés via la liaison série. Ce code est ensuite interprété à l'extrémité distante de la connexion. Cette technique garantit une densité de 1 indépendante du flux de données.

Les anciennes implémentations T1 utilisent le tramage D4, également appelé format Superframe (SF) et codage AMI (Alternate Mark Inversion). AMI n'utilise pas de schéma de codage comme B8ZS. Cela limite le type de données pouvant être transmises, car la densité des uns n'est pas maintenue indépendamment du flux de données.

Un autre élément important dans les communications série est la synchronisation de terminal SCTE (Serial clock Transmission External). SCTE est l’horloge qui résonne du périphérique ETTD (équipement terminal de traitement de données) (par exemple, un routeur) au périphérique ETCD (équipement de communication de données) (par exemple, l’unité CSU/DSU).

Lorsque le périphérique ETCD utilise SCTE au lieu de son horloge interne pour échantillonner les données de l’ETTD, il est préférable d’échantillonner les données sans erreur, même s’il existe un décalage de phase dans le câble entre l’unité CSU/DSU et le routeur. L'utilisation de SCTE est fortement recommandée pour les transmissions série plus rapides que 64 Kbits/s. Si votre unité CSU/DSU ne prend pas en charge SCTE, reportez-vous à la section Inverting the Transmit Clock, plus loin dans ce chapitre.

Causes du problème de synchronisation

En général, les problèmes de synchronisation dans les interconnexions WAN série peuvent être attribués à l'une des causes suivantes :

• Configuration DSU incorrecte

• Configuration CSU incorrecte

• Câbles hors spécifications, c'est-à-dire plus de 15,24 mètres ou non blindés

• Connexions bruyantes ou médiocres du tableau de connexions

• Plusieurs câbles reliés entre eux d'une même ligne

Détection des problèmes de synchronisation

Pour détecter les conflits de synchronisation sur une interface série, recherchez les erreurs d'entrée suivantes :

1. Utilisez la commande EXEC show interfaces serial sur les routeurs aux deux extrémités de la liaison.

2. Examinez le résultat de la commande CRC, les erreurs de tramage et les abandons.

3. Si l'une de ces étapes indique des erreurs dépassant une plage approximative de 0,5 % 2,0 % du trafic sur l'interface, des problèmes de synchronisation risquent d'exister quelque part dans le WAN.

4. Isolez la source des conflits de synchronisation comme indiqué dans la section suivante, Isolating Clock Problems.

5. Contourner ou réparer les tableaux de connexions défectueux.

Isolation des problèmes de synchronisation

Une fois que vous avez déterminé que les conflits de synchronisation sont la cause la plus probable des erreurs d'entrée, la procédure suivante vous aidera à isoler la source de ces erreurs :

1. Effectuez une série de tests ping et de bouclage (locaux et distants), comme décrit dans la section « Tests de bouclage CSU et DSU », plus haut dans ce chapitre.

2. Déterminez la fin de la connexion qui est la source du problème ou si le problème se trouve dans la ligne. En mode de bouclage local, exécutez différents modèles et tailles dans les tests ping (par exemple, utilisez des datagrammes de 1 500 octets). L’utilisation d’un modèle unique et d’une taille de paquet ne peut pas forcer la matérialisation d’erreurs, en particulier lorsqu’un câble série vers le routeur ou l’unité CSU/DSU est le problème.

3. Utilisez la commande EXEC show interfaces serial et déterminez si le nombre d’erreurs d’entrée augmente et où elles s’accumulent.

Si des erreurs d'entrée s'accumulent aux deux extrémités de la connexion, la synchronisation de l'unité CSU est le problème le plus probable.

Si une seule extrémité rencontre des erreurs d’entrée, il y a probablement un problème de câblage ou de synchronisation DSU.

Les abandons d'un côté suggèrent que l'autre extrémité envoie de mauvaises informations ou qu'il y a un problème de ligne.

Remarque : consultez toujours la sortie de la commande show interfaces serial (voir Figure 15-1) et enregistrez toutes les modifications apportées au nombre d'erreurs ou notez si le nombre d'erreurs ne change pas.

Solutions aux problèmes de synchronisation

Tableau 15-8 Lignes série : Problèmes de synchronisation et solutions : Ce tableau présente les solutions suggérées pour les problèmes de synchronisation, en fonction de la source du problème.

Problème possible	Solution
Configuration CSU incorrecte	Déterminez si les unités CSU aux deux extrémités sont d'accord sur la source de l'horloge (locale ou ligne). Si les CSU ne sont pas d'accord, configurez-les de sorte qu'elles le soient. Généralement, la ligne est la source. Vérifiez le paramètre LBO sur l'unité CSU pour vous assurer que l'impédance correspond à celle de la ligne physique. Pour plus d'informations sur la configuration de votre unité CSU, consultez la documentation matérielle de votre unité CSU.
Configuration DSU incorrecte	Déterminez si le mode SCTE est activé sur les DSU aux deux extrémités. Si SCTE n'est pas activé aux deux extrémités de la connexion, activez-le. Assurez-vous que la densité des uns est maintenue. Cela nécessite que l’unité DSU utilise les mêmes schémas de tramage et de codage (par exemple, ESF et B8ZS) utilisés par la ligne louée ou par un autre service de l’opérateur. Consultez votre fournisseur de ligne louée pour obtenir des informations sur ses schémas de tramage et de codage. Si votre service d'opérateur utilise le codage AMI, soit inversez l'horloge de transmission des deux côtés de la liaison, soit exécutez le DSU en mode de liaison binaire. Pour plus d'informations sur la configuration de votre DSU, consultez la documentation matérielle de votre DSU.
Le câble vers le routeur n'est pas conforme aux spécifications	Si le câble mesure plus de 15,24 mètres, utilisez un câble plus court. Si le câble n'est pas blindé, remplacez-le par un câble blindé.

Inversion de l'horloge de transmission

Si vous essayez des connexions série à des vitesses supérieures à 64 kbits/s avec une unité CSU/DSU qui ne prend pas en charge SCTE, vous devrez peut-être inverser l’horloge de transmission sur le routeur. L’inversion de l’horloge de transmission compense les décalages de phase entre les signaux de données et d’horloge.

La commande spécifique utilisée pour inverser l’horloge de transmission varie d’une plate-forme à l’autre. Sur un routeur de la gamme Cisco 7000, entrez la commande de configuration d'interface invert-transmit-clock. Pour les routeurs de la gamme Cisco 4000, utilisez la commande de configuration d’interface dte-invert-txc.

Pour vous assurer que vous utilisez la syntaxe de commande correcte pour votre routeur, reportez-vous au guide de l'utilisateur de votre routeur ou serveur d'accès, ainsi qu'aux guides de configuration et aux références de commandes de Cisco IOS.

Remarque : Sur les plates-formes plus anciennes, inverser l'horloge de transmission peut nécessiter le déplacement d'un cavalier physique.

Réglage des tampons

Une utilisation excessive de la bande passante (plus de 70 %) réduit les performances globales et peut entraîner des pannes intermittentes. Par exemple, les transmissions de fichiers DECnet peuvent échouer en raison de paquets abandonnés quelque part dans le réseau.

Si la situation est suffisamment mauvaise, vous devez augmenter la bande passante de la liaison. Cependant, l'augmentation de la bande passante peut ne pas être nécessaire ou immédiatement pratique. Une façon de résoudre les problèmes de surutilisation de ligne série marginale consiste à contrôler la manière dont le routeur utilise les tampons de données.

Attention : En règle générale, ne modifiez pas les tampons système à moins que vous ne travailliez en étroite collaboration avec un représentant du support technique Cisco. Vous pouvez affecter gravement les performances de votre matériel et de votre réseau si vous ajustez incorrectement les tampons système sur votre routeur.

Utilisez l'une des trois options suivantes pour contrôler l'utilisation des tampons :

• Ajuster les paramètres associés aux tampons système

• Spécifier le nombre de paquets détenus dans les files d'attente d'entrée ou de sortie (files d'attente)

• Hiérarchiser le mode de mise en file d'attente du trafic pour la transmission (mise en file d'attente de sortie prioritaire)

Les commandes de configuration associées à ces options sont décrites dans les guides de configuration et les références de commandes de Cisco IOS.

La section suivante se concentre sur l'identification des situations dans lesquelles ces options sont susceptibles de s'appliquer et la définition de la manière dont vous pouvez utiliser ces options pour résoudre les problèmes de connectivité et de performances dans les interconnexions série/WAN.

Réglage des tampons système

Il existe deux types généraux de mémoire tampon sur les routeurs Cisco : les mémoires tampon matérielles et les mémoires tampon système. Seules les mémoires tampon système peuvent être configurées directement par les administrateurs système. Les tampons matériels sont spécifiquement utilisés comme tampons de réception et de transmission associés à chaque interface et (en l'absence de configuration spéciale) sont gérés dynamiquement par le logiciel système lui-même.

Les mémoires tampon système sont associées à la mémoire système principale et sont allouées à des blocs de mémoire de taille différente. Une commande utile pour déterminer l'état de vos mémoires tampon système est la commande EXEC show buffers. La Figure 15-8 présente le résultat de la commande show buffers.

Figure 15-8 Sortie de la commande show buffers

Dans la sortie show buffers :

• total - Identifie le nombre total de mémoires tampon dans le pool, y compris les mémoires tampon utilisées et inutilisées.

• permanent - Identifie le nombre permanent de tampons alloués dans le pool. Ces tampons sont toujours dans le pool et ne peuvent pas être éliminés.

• dans la liste libre - Identifie le nombre de tampons actuellement dans le pool qui sont disponibles pour utilisation.

• min - Identifie le nombre minimal de mémoires tampon que le processeur de routage (RP) doit tenter de conserver dans la liste libre :

  • Le paramètre min est utilisé pour anticiper la demande de tampons du pool à un moment donné.

  • Si le nombre de mémoires tampon dans la liste libre est inférieur à la valeur min, le RP tente de créer plus de mémoires tampon pour ce pool.

• max allowed - Identifie le nombre maximal de tampons autorisés dans la liste libre :

  • Le paramètre max allowed empêche un pool de monopoliser les tampons dont il n'a plus besoin et libère cette mémoire au système pour une utilisation ultérieure.

  • Si le nombre de tampons dans la liste libre est supérieur à la valeur maximale autorisée, le RP doit tenter de réduire les tampons à partir du pool.

• hits - Identifie le nombre de mémoires tampon qui ont été demandées au pool. Le compteur d'accès fournit un mécanisme permettant de déterminer quel pool doit répondre à la demande la plus élevée pour les tampons.

• manques - Identifie le nombre de fois où une mémoire tampon a été demandée et le RP a détecté que des mémoires tampon supplémentaires étaient nécessaires. (En d'autres termes, le nombre de tampons dans la liste libre a chuté en dessous de la min.) Le compteur manquant représente le nombre de fois où le RP a été forcé de créer des mémoires tampon supplémentaires.

• trims - Identifie le nombre de mémoires tampon que le RP a coupées à partir du pool lorsque le nombre de mémoires tampon dans la liste libre dépasse le nombre de mémoires tampon max. autorisées.

• create - Identifie le nombre de mémoires tampon créées dans le pool. Le RP crée des tampons lorsque la demande pour les tampons a augmenté jusqu'à ce que le nombre de tampons dans la liste libre soit inférieur à la min buffers et/ou qu'une erreur se produise à cause de zéro tampon dans la liste libre.

• échecs - Identifie le nombre d'échecs d'octroi d'une mémoire tampon à un demandeur même après avoir tenté de créer une mémoire tampon supplémentaire. Le nombre d'échecs représente le nombre de paquets abandonnés en raison d'une pénurie de mémoire tampon.

• no memory - Identifie le nombre de pannes causées par une mémoire insuffisante pour créer des mémoires tampon supplémentaires.

La sortie de la commande show buffers de la Figure 15-8 indique des nombres élevés dans les trims et les champs créés pour les mémoires tampon volumineuses. Si vous recevez des nombres élevés dans ces champs, vous pouvez augmenter les performances de la liaison série en augmentant la valeur libre maximale configurée pour vos tampons système. trims identifie le nombre de tampons que le RP a coupé du pool lorsque le nombre de tampons dans la liste libre a dépassé le nombre de tampons max autorisés.

Utilisez la commande de configuration globale buffers max free number pour augmenter le nombre de mémoires tampon système libres. La valeur que vous configurez doit être d'environ 150 % de la figure indiquée dans le champ total du résultat de la commande show buffers. Répétez ce processus jusqu'à ce que la sortie show buffers n'indique plus les trims et les tampons créés.

Si la sortie de la commande show buffers montre un grand nombre de pannes dans le champ (pas de mémoire) (voir la dernière ligne de la sortie de la figure 15-8), vous devez réduire l'utilisation des tampons système ou augmenter la quantité de mémoire partagée ou principale (mémoire vive physique) sur le routeur. Contactez votre représentant du support technique pour obtenir de l'aide.

Implémentation des limites de file d'attente en attente

Les files d’attente sont des tampons utilisés par chaque interface de routeur pour stocker les paquets sortants ou entrants. Utilisez la commande de configuration d'interface hold-queue pour augmenter le nombre de paquets de données mis en file d'attente avant que le routeur abandonne les paquets. Augmentez ces files d'attente par petits incréments (par exemple, 25 %) jusqu'à ce que vous ne voyiez plus de pertes dans la sortie show interfaces. La limite de la file d'attente de sortie par défaut est de 100 paquets.

Remarque : La commande hold-queue est utilisée pour les paquets à commutation de processus et les mises à jour périodiques générées par le routeur.

Utilisez la commande hold-queue pour empêcher l'abandon des paquets et améliorer les performances de liaison série dans les conditions suivantes :

• Vous avez une application qui ne peut pas tolérer les abandons et le protocole peut tolérer des retards plus longs. DECnet est un exemple de protocole qui répond aux deux critères. Le transport local (LAT) ne tolère pas les retards.

• L'interface est très lente. La bande passante est faible ou l’utilisation prévue risque de dépasser sporadiquement la bande passante disponible.

Remarque : lorsque vous augmentez le nombre spécifié pour une file d'attente de sortie en attente, vous devrez peut-être augmenter le nombre de mémoires tampon système. La valeur utilisée dépend de la taille des paquets associés au trafic prévu pour le réseau.

Utilisation de la mise en file d'attente par priorité pour réduire les goulots d'étranglement

La mise en file d'attente par priorité est un mécanisme de contrôle basé sur des listes qui permet de hiérarchiser le trafic sur une base interface par interface. La mise en file d’attente par priorité comporte deux étapes :

1. Créez une liste de priorités par type de protocole et niveau de priorité.

2. Attribuez la liste de priorités à une interface spécifique.

Ces deux étapes utilisent des versions de la commande de configuration globale priority-list. En outre, le contrôle du trafic peut être appliqué en référençant les commandes de configuration globale access-list à partir des spécifications priority-list. Pour obtenir des exemples de définition des listes de priorité et des détails sur la syntaxe des commandes associées à la mise en file d'attente prioritaire, reportez-vous aux guides de configuration et aux références des commandes de Cisco IOS.

Remarque : La mise en file d'attente par priorité crée automatiquement quatre files d'attente de taille variable. Ceci remplace toute spécification de file d'attente d'attente incluse dans votre configuration.

Utilisez la mise en file d’attente prioritaire pour empêcher la suppression des paquets et améliorer les performances de la liaison série dans les conditions suivantes :

• Lorsque l’interface est lente, divers types de trafic sont transmis et vous voulez améliorer les performances du trafic du terminal.

• Si vous avez une liaison série qui subit des charges très lourdes de façon intermittente (par exemple des transferts de fichiers se produisant à des moments spécifiques), la mise en file d'attente par priorité vous aidera à sélectionner les types de trafic qui doivent être abandonnés lors de périodes de trafic élevé.

En général, commencez par le nombre par défaut de files d'attente lors de l'implémentation de files d'attente prioritaires. Après avoir activé la mise en file d'attente par priorité, la sortie du moniteur est abandonnée à l'aide de la commande EXEC show interfaces serial. Si vous remarquez que des pertes de sortie se produisent dans la file d'attente de trafic que vous avez spécifiée comme hautement prioritaire, augmentez le nombre de paquets qui peuvent être mis en file d'attente (en utilisant l'option mot clé queue-limit de la commande de configuration globale priority-list). Les arguments de limite de file d'attente par défaut sont 20 paquets pour la file d'attente prioritaire, 40 pour la file d'attente moyenne, 60 pour la file d'attente normale et 80 pour la file d'attente basse.

Remarque : lors du pontage du trafic LAT de Digital Equipment Corporation (DEC), le routeur doit abandonner très peu de paquets ou les sessions LAT peuvent se terminer de manière inattendue. Une profondeur de file d'attente de priorité élevée d'environ 100 (spécifiée avec le mot clé queue-limit) est une valeur de travail typique lorsque votre routeur abandonne des paquets de sortie et que les lignes série sont soumises à une utilisation de la bande passante d'environ 50 %. Si le routeur abandonne des paquets et qu'il est utilisé à 100 %, vous avez besoin d'une autre ligne.

La compression LAT est un autre outil permettant de réduire l'encombrement lors du pontage DEC LAT. Vous pouvez implémenter la compression LAT avec la commande de configuration d'interface bridge-group group lat-compression.

Tests de ligne série spéciaux

Outre les fonctionnalités de diagnostic de base disponibles sur les routeurs, divers outils et techniques supplémentaires peuvent être utilisés pour déterminer les conditions des câbles, de l’équipement de commutation, des modems, des hôtes et du matériel d’interconnexion de réseaux à distance. Pour plus d'informations, consultez la documentation de votre unité CSU, DSU, analyseur série ou autre équipement.

Tests de bouclage CSU et DSU

Si le résultat de la commande EXEC show interfaces serial indique que la ligne série est active mais que le protocole de ligne est désactivé, utilisez les tests de bouclage CSU/DSU pour déterminer la source du problème. Effectuez d'abord le test de boucle locale, puis le test à distance. La figure 15-9 illustre la topologie de base des tests de bouclage locaux et distants CSU/DSU.

Figure 15-9 : Tests de bouclage local et distant CSU/DSU

Remarque : ces tests sont de nature générique et supposent l'attachement du système d'interconnexion à une unité CSU ou DSU. Cependant, les tests sont essentiellement les mêmes pour la connexion à un multiplexeur avec une fonctionnalité CSU/DSU intégrée. Comme il n'existe aucun concept de bouclage dans les environnements X.25 ou PSN (Frame Relay Packet-Switched Network), les tests de bouclage ne s'appliquent pas aux réseaux X.25 et Frame Relay.

Tests de bouclage local CSU et DSU pour les liaisons HDLC ou PPP

Vous trouverez ci-dessous une procédure générale pour effectuer des tests de bouclage en conjonction avec des fonctionnalités de diagnostic système intégrées :

1. Placez l'unité CSU/DSU en mode boucle locale (reportez-vous à la documentation de votre fournisseur). En mode boucle locale, l’utilisation de l’horloge de ligne (à partir du service T1) est interrompue et l’unité DSU est contrainte d’utiliser l’horloge locale.

2. Utilisez la commande EXEC show interfaces serial pour déterminer si l'état de la ligne passe de « line protocol is down » à « line protocol is up (looped)" ou s'il reste désactivé.

3. Si le protocole de ligne apparaît lorsque l’unité CSU ou DSU est en mode de bouclage local, cela suggère que le problème se produit à l’extrémité distante de la connexion série. Si la ligne d’état ne change pas d’état, un problème peut survenir dans le routeur, le câble de connexion ou l’unité CSU/DSU.

4. Si le problème semble être local, utilisez la commande EXEC privilégiée debug serial interface.

5. Sortez l’unité CSU/DSU du mode boucle locale. Lorsque le protocole de ligne est désactivé, la sortie de commande debug serial interface indique que les compteurs keepalive ne sont pas incrémentés.

6. Repassez l’unité CSU/DSU en mode boucle locale. Cela devrait faire en sorte que les paquets keepalive commencent à s'incrémenter. Plus précisément, les valeurs pour les keepalives mineseen et votrevues seront incrémentées toutes les 10 secondes. Ces informations apparaîtront dans la sortie de l'interface série de débogage.

   Si les keepalives ne s'incrémentent pas, il peut y avoir un problème de synchronisation sur la carte d'interface ou sur le réseau. Pour plus d'informations sur la correction des problèmes de synchronisation, reportez-vous à la section Dépannage des problèmes de synchronisation, plus haut dans ce chapitre.

   Si les keepalives ne s'incrémentent pas, il peut y avoir un problème de synchronisation sur la carte d'interface ou sur le réseau. Pour plus d'informations sur la correction des problèmes de synchronisation, reportez-vous à la section Dépannage des problèmes de synchronisation, plus haut dans ce chapitre.

7. Vérifiez le routeur local, le matériel CSU/DSU et tous les câbles connectés. Assurez-vous que les câbles sont dans les longueurs recommandées (pas plus de 15,24 mètres) ou 7,62 mètres) pour une liaison T1. Vérifiez que les câbles sont reliés aux ports appropriés. Remplacez le matériel défectueux si nécessaire.

La Figure 15-10 présente le résultat de la commande debug serial interface pour une connexion série HDLC, avec des messages de test d'activité manqués entraînant la désactivation de la ligne et la réinitialisation de l'interface.

Figure 15-10 : Sortie de la commande debug serial interface

Tests de bouclage à distance CSU et DSU pour les liaisons HDLC ou PPP

Si vous déterminez que le matériel local fonctionne correctement mais que vous rencontrez toujours des problèmes lors de la tentative d'établissement de connexions sur la liaison série, essayez d'utiliser le test de bouclage à distance pour isoler la cause du problème.

Remarque : Ce test de bouclage à distance suppose que l'encapsulation HDLC est utilisée et que le test de boucle locale précédent a été effectué immédiatement avant ce test.

Les étapes suivantes sont requises pour effectuer des tests de bouclage :Les étapes suivantes sont requises pour effectuer des tests de bouclage :

1. Mettre l'unité CSU ou DSU distante en mode bouclé à distance (reportez-vous à la documentation du fournisseur).

2. À l'aide de la commande EXEC show interfaces serial, déterminez si le protocole de ligne reste actif avec la ligne d'état indiquant « Serial x is up, line protocol is up (looped)" ou s'il est désactivé avec la ligne d'état indiquant « line protocol is down ».

3. Si le protocole de ligne reste actif (en boucle), le problème se situe probablement à l’extrémité distante de la connexion série (entre l’unité CSU/DSU distante et le routeur distant). Effectuez des tests locaux et distants à l'extrémité distante pour isoler la source du problème.

4. Si l'état de la ligne passe à « line protocol is down » lorsque le mode de bouclage distant est activé, assurez-vous que la densité des uns est correctement maintenue. L’unité CSU/DSU doit être configurée pour utiliser les mêmes schémas de tramage et de codage que ceux utilisés par la ligne louée ou d’autres services de l’opérateur (par exemple, ESF et B8ZS).

5. Si des problèmes persistent, contactez votre administrateur réseau WAN ou l'organisation de services WAN.

Informations détaillées sur la commande show interfaces serial

Les sous-sections suivantes traitent des paramètres de la commande show interfaces serial, de la description de la syntaxe, de l'affichage des résultats d'exemple et des descriptions des champs.

show interfaces serial Parameters

Pour afficher des informations sur une interface série, utilisez la commande EXEC privilégiée show interfaces serial :

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)

Description de la syntaxe

• number-Facultatif. Port number (numéro de port) .

• accounting-Facultatif. Affiche le nombre de paquets de chaque type de protocole qui ont été envoyés via l'interface.

• :channel-group - Facultatif. Sur la gamme Cisco 4000 avec un NPM ou une gamme Cisco 7500 avec un MIP, spécifie le numéro de groupe de canaux T1 dans la plage de 0 à 23, défini avec la commande de configuration du contrôleur channel-group.

• slot - Se rapporte au manuel matériel approprié pour obtenir des informations sur les logements.

• port - Se rapporte au manuel matériel approprié pour les informations sur les ports.

• port-adapter - Se rapporte au manuel matériel approprié pour obtenir des informations sur la compatibilité de la carte de port.

• :t1-channel - Facultatif. Pour le CT3IP, le canal T1 est un nombre compris entre 1 et 28.

• Les canaux T1 du CT3IP sont numérotés de 1 à 28 plutôt que le schéma plus traditionnel basé sur zéro (0 à 27) utilisé avec d'autres produits Cisco. Cela permet d’assurer la cohérence avec les schémas de numérotation Telco pour les canaux T1 au sein des équipements T3 multicanaux fractionnés.

• crb-Facultatif. Affiche les informations de routage et de pontage des interfaces.

Mode Commande

EXEC privilégié

Directives d'utilisation

Cette commande est apparue pour la première fois dans la version 10.0 de Cisco IOS pour la gamme Cisco 4000. Il est apparu pour la première fois dans la version 11.0 de Cisco IOS pour la gamme Cisco 7000 et a été modifié dans la version 11.3 de Cisco IOS pour inclure le CT3IP.

Exemples d'affichage

Voici un exemple de sortie de la commande show interfaces pour une interface série synchrone :

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

Description du champ

Tableau 15-9 : show interfaces serial Field Descriptions - ce tableau décrit les champs significatifs affichés dans le résultat.

Champ	Description
Série...est {up | down}..est désactivé sur le plan administratif	Indique si le matériel de l'interface est actuellement actif (la détection de porteuse est présente) ou s'il a été arrêté par un administrateur.
Le protocole de ligne est {up | désactivé}	Indique si les processus logiciels qui gèrent le protocole de ligne considèrent que la ligne est utilisable (c'est-à-dire que les keepalives ont réussi) ou si elle a été arrêtée par un administrateur.
Le protocole de ligne est {up | désactivé}	Indique si les processus logiciels qui gèrent le protocole de ligne considèrent que la ligne est utilisable (c'est-à-dire que les keepalives ont réussi) ou si elle a été arrêtée par un administrateur.
Le matériel est	Spécifie le type de matériel.
L'adresse Internet est	Spécifie l'adresse Internet et le masque de sous-réseau.
MTU	Unité de transmission maximale de l’interface.
BW	Indique la valeur du paramètre de bande passante configuré pour l'interface (en kilobits par seconde). Le paramètre de bande passante est utilisé uniquement pour calculer les métriques IGRP. Si l'interface est connectée à une ligne série dont la vitesse de ligne ne correspond pas à la valeur par défaut (1536 ou 1544 pour T1 et 56 pour une ligne série synchrone standard), utilisez la commande bandwidth pour spécifier la vitesse de ligne correcte pour cette ligne série.
DENT	Délai de l'interface en microsecondes.
de confiance	Fiabilité de l'interface en une fraction de 255 (255/255 correspond à une fiabilité de 100 %), calculée comme une moyenne exponentielle sur cinq minutes.
charge	Fiabilité de l'interface en une fraction de 255 (255/255 correspond à une fiabilité de 100 %), calculée comme une moyenne exponentielle sur cinq minutes.
Encapsulation	Méthode d’encapsulation affectée à l’interface.
bouclage	Indique si le bouclage est défini.
keepalive	Indique si les keepalives sont définis.
Dernière entrée	Nombre d’heures, de minutes et de secondes depuis la réception du dernier paquet par une interface. Utile pour savoir quand une interface morte a échoué.
Dernière sortie	Nombre d’heures, de minutes et de secondes depuis la transmission du dernier paquet par une interface.Nombre d’heures, de minutes et de secondes depuis la transmission du dernier paquet par une interface.
attente de sortie	Nombre d’heures, de minutes et de secondes (ou jamais) depuis la dernière réinitialisation de l’interface en raison d’une transmission trop longue. Lorsque le nombre d'heures dans l'un des derniers champs dépasse 24, le nombre de jours et d'heures est imprimé. Si ce champ déborde, des astérisques sont imprimés.
File d'attente de sortie, abandonne la file d'attente d'entrée, abandonne	Nombre de paquets dans les files d'attente de sortie et d'entrée. Chaque numéro est suivi d'une barre oblique, de la taille maximale de la file d'attente et du nombre de paquets car la file d'attente est pleine.
Vitesse d'entrée de 5 minutes	Nombre moyen de bits et de paquets transmis par seconde au cours des cinq dernières minutes. Les débits d'entrée et de sortie de cinq minutes ne doivent être utilisés qu'en tant qu'approximation du trafic par seconde pendant une période donnée de cinq minutes. Ces taux sont des moyennes pondérées de façon exponentielle avec une constante de temps de cinq minutes. Une période de quatre constantes de temps doit passer avant que la moyenne ne soit inférieure à 2 % du taux instantané d'un flux de trafic uniforme sur cette période.
entrée de paquets	Nombre total de paquets sans erreur reçus par le système.
octets	Nombre total d'octets, y compris les données et l'encapsulation MAC, dans les paquets sans erreur reçus par le système.
no buffer	Nombre de paquets reçus ignorés car il n'y avait pas d'espace tampon dans le système principal. Comparez cette valeur avec la valeur du compteur ignored. Les tempêtes de diffusion sur les réseaux Ethernet et les rafales de bruit sur les lignes série sont souvent responsables de l’absence d’événements de tampon d’entrée.
Reçu... diffusions	Nombre total de paquets de diffusion ou de multidiffusion reçus par l’interface.
arêtes	Nombre de paquets rejetés car ils sont plus petits que la taille minimale de paquet du support.
géant	Nombre de paquets rejetés car ils dépassent la taille maximale de paquet du support.
erreurs d'entrée	Nombre total de mémoires tampons, d'exécutions, de géants, de CRC, de trames, de dépassements, d'ignorés et d'abandons. D'autres erreurs liées à l'entrée peuvent également incrémenter le nombre, de sorte que cette somme peut ne pas correspondre aux autres nombres.
CRC	Le contrôle de redondance cyclique généré par la station d'origine ou le périphérique distant ne correspond pas à la somme de contrôle calculée à partir des données reçues. Sur une liaison série, les CRC indiquent généralement le bruit, les résultats positifs ou d’autres problèmes de transmission sur la liaison de données.
trame	Nombre de paquets reçus de manière incorrecte avec une erreur CRC et un nombre non entier d’octets. Sur une ligne série, il s’agit généralement du résultat d’un bruit ou d’autres problèmes de transmission.
surcharger	Nombre de fois où le matériel du récepteur série n'a pas pu remettre les données reçues à un tampon matériel, car le débit d'entrée dépassait la capacité du récepteur à gérer les données.
ignoré	Nombre de paquets reçus ignorés par l'interface, car le matériel de l'interface ne fonctionnait pas correctement sur les tampons internes. Des tempêtes de diffusion et les rafales de bruit peuvent entraîner l'augmentation du compteur ignored.
abandonner	Séquence non autorisée d’un bit sur une interface série. Cela indique généralement un problème de synchronisation entre l’interface série et l’équipement de liaison de données.
transitions de porteuse	Nombre de fois où le signal de détection de porteuse d’une interface série a changé d’état. Par exemple, si la détection de porteuse de données (DCD) tombe en panne et s'active, le compteur de transition de porteuse s'incrémente deux fois. Indique des problèmes de modem ou de ligne si la ligne de détection de l'opérateur change souvent d'état.
sortie de paquets	Nombre total de messages transmis par le système.
sortie d'octets	Nombre total d'octets, y compris les données et l'encapsulation MAC, transmis par le système.
sous-jacents	Nombre de fois que l'émetteur s'exécute plus rapidement que le routeur ne peut gérer. Cela ne peut jamais être signalé sur certaines interfaces.
output errors	Somme de toutes les erreurs qui ont empêché la transmission finale des datagrammes hors de l’interface examinée. Notez que ceci peut ne pas correspondre à la somme des erreurs de sortie énumérées, car certains datagrammes peuvent avoir plusieurs erreurs, tandis que d'autres peuvent avoir des erreurs qui ne tombent dans aucune des catégories spécifiquement tabulées.
collisions	Nombre de messages retransmis en raison d’une collision Ethernet. Cela résulte généralement d'un réseau local surétendu (c'est-à-dire d'un câble Ethernet ou émetteur-récepteur trop long, de plus de deux répéteurs entre les stations ou d'un trop grand nombre d'émetteurs-récepteurs multiports en cascade). Certaines collisions sont normales. Cependant, si votre taux de collision grimpe à environ 4 ou 5 %, vous devriez envisager de vérifier qu'il n'y a pas d'équipement défectueux sur le segment et/ou de déplacer certaines stations existantes vers un nouveau segment. Un paquet qui entre en collision n'est compté qu'une seule fois dans les paquets de sortie.
réinitialisation d'interface	Nombre de fois où une interface a été complètement réinitialisée. Cela peut se produire si les paquets mis en file d'attente pour transmission n'ont pas été envoyés dans un délai de plusieurs secondes. Sur une ligne série, cela peut être dû à un modem défectueux qui ne fournit pas le signal d’horloge de transmission ou à un problème de câble. Si le système remarque que la ligne de détection de porteuse d'une interface série est active mais que le protocole de ligne est désactivé, il réinitialise périodiquement l'interface afin de la redémarrer. Les réinitialisations d'interface peuvent également se produire lorsqu'une interface est bouclée ou arrêtée.
redémarre	Nombre de fois où le contrôleur a été redémarré en raison d'erreurs.
indications d'alarme, alarmes distantes, Rx LOF, Rx LOS	Nombre d'alarmes CSU/DSU et nombre d'occurrences de perte de trame et de perte de signal de réception.
BER inactif, NELR inactif, FELR inactif	État des compteurs G.703-E1 pour l'alarme BER (bit error rate), NELR (Near-End loop remote) et FELR (far-end loop remote). Notez que vous ne pouvez pas définir le NELR ou le FELR.

Dépannage de T1

Cette section décrit les techniques et procédures de dépannage des circuits T1 pour les clients commutés.

Dépannage à l'aide de la commande show controller t1

Cette commande affiche l'état du contrôleur spécifique au matériel du contrôleur. Les informations affichées sont généralement utiles pour les tâches de diagnostic effectuées uniquement par le personnel d'assistance technique.

Le NMP (Network Management Processor) ou le MIP (MultiChannel Interface Processor) peut interroger les cartes de ports pour déterminer leur état actuel. Exécutez une commande show controller t1 pour afficher des statistiques sur la liaison T1.

Si vous spécifiez un emplacement et un numéro de port, des statistiques s'affichent pour chaque période de 15 minutes. La commande EXEC show controller t1 fournit des informations permettant de résoudre logiquement les problèmes de couche physique et de couche liaison de données. Cette section décrit comment dépanner logiquement à l'aide de la commande show controller t1.

La plupart des erreurs T1 sont causées par des lignes mal configurées. Assurez-vous que l'encodage de ligne, le tramage et la source d'horloge sont configurés conformément aux recommandations du fournisseur de services.

show controller t1 Conditions

Le contrôleur T1 peut se trouver dans l'un des trois états suivants.

• Administrativement inactif

• Vers le bas

• Monter

Le contrôleur T1 est-il désactivé administrativement ?

Le contrôleur est désactivé par l'administrateur lorsqu'il a été arrêté manuellement. Vous devez redémarrer le contrôleur pour corriger cette erreur.

1. Passez en mode enable.

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

2. Entrez le mode de configuration globale .

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

3. Passez en mode de configuration du contrôleur.

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

4. Redémarrer le contrôleur.

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

La mise en ligne est-elle terminée ?

Si le contrôleur T1 et la ligne ne sont pas activés, vérifiez si l'un des messages suivants apparaît dans la sortie EXEC show controller t1 :

• Le récepteur a perdu la trame

• Le récepteur a une perte de signal

Si le récepteur T1 a perdu la trame :

Suivez ces étapes si le récepteur T1 a perdu une trame :

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Vous pouvez vérifier le format de trame du contrôleur à partir de la configuration en cours ou de la sortie de la commande show controller t1.

   Pour modifier le format de trame, utilisez le tramage {SF | ESF} en mode de configuration du contrôleur, comme indiqué ci-dessous :

   maui-nas-03#configure terminal
   

   Entrez les commandes de configuration, une par ligne. Terminer par CNTL/Z.

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

2. Essayez l'autre format de tramage pour voir si l'alarme s'efface.

3. Modifiez le paramètre d'accumulation de lignes à l'aide de la longueur de câble {long | short} .

La configuration en ligne (LBO) compense la perte en décibels en fonction de la distance entre le périphérique et le premier répéteur du circuit. Une distance plus longue entre le périphérique et le répéteur nécessite que la puissance du signal sur le circuit soit redémarrée pour compenser la perte sur cette distance.

Pour plus d'informations sur les paramètres d'installation, consultez votre fournisseur de services et la référence des commandes Cisco IOSĆ.

Si cela ne résout pas le problème, reportez-vous à la section « If T1 Receiver Has Loss of Signal » ci-dessous.

Si le récepteur T1 a perdu le signal :

Suivez ces étapes si le récepteur T1 a perdu le signal :

1. Assurez-vous que le câble entre le port d'interface et l'équipement du fournisseur de services T1 (ou l'équipement terminal T1) est correctement connecté. Vérifiez si le câble est branché sur les ports appropriés. Corrigez les connexions des câbles au besoin.

2. Vérifiez l'intégrité des câbles. Recherchez des pauses ou d’autres anomalies physiques dans le câble. Vérifiez que les brochages sont correctement définis. Si nécessaire, remplacez le câble.

3. Vérifiez les connecteurs du câble. Une inversion des paires de transmission et de réception ou une paire de réception ouverte peut provoquer des erreurs. Définissez la paire de réception sur les lignes 1 et 2. Définissez la paire de transmission sur les lignes 4 et 5.

   Les broches d'une prise RJ-45 sont numérotées de 1 à 8. La broche 1 est la broche la plus à gauche lorsque vous regardez la prise avec les broches métalliques qui vous font face. Reportez-vous à la figure ci-dessous.

   Figure 15-10 : Câble RJ-45

   

4. Essayez d'utiliser un câble à paires inversées.

Exécutez la commande EXEC show controller t1 après chaque étape pour vérifier si le contrôleur présente des erreurs.

Vérifiez si la ligne est en mode bouclage à partir de la sortie show controller t1. Une ligne doit être en mode bouclage uniquement à des fins de test.

Pour désactiver le bouclage, utilisez la commande no loopback en mode de configuration du contrôleur, comme indiqué ci-dessous :

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

Si le contrôleur affiche des alarmes :

Vérifiez la sortie de la commande show controller pour voir s'il y a des alarmes affichées par le contrôleur.

Nous allons maintenant discuter des différentes alarmes et de la procédure nécessaire pour les corriger.

Signal d'indication d'alarme de réception (RX) (bleu) :

Un signal d'indication d'alarme reçu (AIS) signifie qu'une alarme se produit sur la ligne en amont de l'équipement connecté au port.

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Si ce n'est pas le cas, modifiez le format de trame sur le contrôleur pour qu'il corresponde à celui de la ligne.

2. Contactez votre fournisseur de services pour vérifier la configuration incorrecte au sein de l'opérateur téléphonique.

Reçoit (Rx) Remote Alarm Indication (RAI) (Jaune) :

Une RAI reçue signifie que l’équipement distant a un problème avec le signal qu’il reçoit de son équipement en amont.

1. Insérez un câble externe de rebouclage dans le port. Pour créer une fiche de bouclage, reportez-vous à la section Création d'une fiche de bouclage, plus loin dans le chapitre.

2. Vérifiez s'il y a des alarmes. Si aucune alarme ne s'affiche, le matériel local est probablement en bon état. Dans ce cas :

   1. Vérifiez le câblage. Pour plus d'informations, reportez-vous à la section « If T1 Receiver Has Loss of Signal ».

   2. Vérifiez les paramètres de l’extrémité distante et vérifiez qu’ils correspondent à vos paramètres de port.

   3. Si le problème persiste, communiquez avec votre fournisseur de services.

3. Retirez la fiche de bouclage et reconnectez votre ligne T1.

4. Vérifiez le câblage. Pour plus d'informations, reportez-vous à la section « If T1 Receiver Has Loss of Signal ».

5. Mettez le routeur hors tension puis sous tension.

6. Connectez la ligne T1 à un autre port. Configurez le port avec les mêmes paramètres que ceux de la ligne. Si le problème ne persiste pas, la défaillance se situe sur le port unique :

   1. Reconnectez la ligne T1 au port d'origine.

   2. Passez à la section Dépannage des événements d'erreur T1.

      Si le problème persiste, alors :

7. Effectuez un test de boucle matérielle comme décrit dans la section « Exécution du test de boucle de bouclage matériel ».

8. Remplacez la carte contrôleur T1.

9. Passez à la section Dépannage des événements d'erreur T1.

Émetteur envoyant une alarme à distance (rouge) :

Une alarme rouge est déclarée lorsque l'unité CSU ne peut pas se synchroniser avec le modèle de tramage sur la ligne T1.

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Si ce n'est pas le cas, modifiez le format de trame sur le contrôleur pour qu'il corresponde à celui de la ligne.

2. Vérifiez les paramètres de l’extrémité distante et vérifiez qu’ils correspondent à vos paramètres de port.

3. Contactez votre fournisseur de services.

Indication d'alarme à distance (RAI) (Jaune) de transmission(Tx) :

Une RAI transmise à l’interface indique que l’interface a un problème avec le signal qu’elle reçoit de l’équipement distant.

1. Vérifiez les paramètres de l’extrémité distante et vérifiez qu’ils correspondent à vos paramètres de port.

2. Un RAI de transmission doit être accompagné d’une autre alarme qui indique la nature du problème que rencontre le port/la carte T1 avec le signal provenant de l’équipement d’extrémité.

Dépannez cette condition pour résoudre le RAI de transmission.

AIS de transmission (Tx) (bleu) :

Suivez les étapes ci-dessous pour corriger l'AIS de transmission (Tx) (bleu).

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Si ce n'est pas le cas, corrigez la non-correspondance.

2. Mettez le routeur hors tension puis sous tension.

3. Connectez la ligne T1 à un autre port. Configurez le port avec les mêmes paramètres que ceux de la ligne.

4. Effectuez un test de boucle matérielle comme décrit dans la section « Exécution du test de boucle de bouclage matériel ».

5. Remplacez la carte contrôleur T1.

6. Passez à la section Dépannage des événements d'erreur T1.

Dépannage des événements d'erreur T1

La commande EXEC show controller t1 fournit des messages d'erreur qui peuvent être utilisés pour résoudre des problèmes. Nous allons maintenant discuter de plusieurs messages d'erreur et de la façon de corriger les erreurs.

Pour voir si les compteurs d'erreurs augmentent, exécutez la commande show controller t1 à plusieurs reprises. Notez les valeurs des compteurs pour l'intervalle actuel.

Consultez votre fournisseur de services pour connaître les paramètres de tramage et de codages. Une bonne règle générale est d'utiliser la codages B8ZS avec le cadre ESF et la codages AMI avec le cadre SF.

Le compteur de secondes de glissement augmente :

La présence de feuillets sur une ligne T1 indique un problème de synchronisation. Le fournisseur T1 (Telco) fournira l'horloge à laquelle l'équipement client (CPE) doit être synchronisé.

1. Vérifiez que la source d'horloge provient du réseau. Pour cela, il suffit de rechercher Clock Source is Line Primary.

   Remarque : S'il y a plusieurs T1 dans un serveur d'accès, un seul peut être le serveur principal, tandis que les autres T1 dérivent l'horloge du serveur principal. Dans ce cas, vérifiez que la ligne T1 désignée comme source d'horloge principale est correctement configurée.

2. Définissez correctement la source d'horloge T1 à partir du mode de configuration du contrôleur.

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

Le compteur de pertes de trames en secondes augmente :

Suivez ces étapes lorsque le compteur de pertes de trames augmente.

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Vous pouvez vérifier cela en recherchant le verrouillage de trame est {ESF|SF} dans la sortie show controller t1.

2. Pour modifier le format de tramage, utilisez le tramage {SF | ESF} en mode de configuration du contrôleur, comme indiqué ci-dessous :

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

3. Modifier l'accumulation de lignes à l'aide de la longueur de câble {long | short}.

Pour plus d'informations sur les paramètres d'installation, consultez votre fournisseur de services et la référence des commandes Cisco IOSĆ.

Les violations de code de ligne augmentent :

Suivez ces étapes lorsque les violations de code de ligne augmentent.

1. Vérifiez si l'écrêtage de ligne configuré sur le port correspond au format de trame de la ligne. Vous pouvez vérifier cela en recherchant le code de ligne {B8ZS|AMI} dans la sortie show controller t1.

2. Pour modifier l'écrêtage de ligne, utilisez le code de ligne {ami | b8zs} en mode de configuration du contrôleur, comme indiqué ci-dessous :

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

3. Modifier l'accumulation de lignes à l'aide de la longueur de câble {long | short}.

Pour plus d'informations sur les paramètres de build, consultez votre fournisseur de services et la référence des commandes Cisco IOS®.

Vérification de la configuration correcte du type de commutateur RNIS et du groupe PRI

Utilisez la commande show running-config pour vérifier si le type de commutateur RNIS et les intervalles de temps du groupe PRI sont configurés correctement. Contactez votre fournisseur de services pour connaître les valeurs correctes.

Pour modifier le type de commutateur RNIS et le groupe 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

Vérification du canal de signalisation

Si les compteurs d'erreur n'augmentent pas mais que le problème persiste, vérifiez que le canal de signalisation est actif et configuré correctement.

1. Exécutez la commande show interface serial x:23, où x doit être remplacé par le numéro d'interface.

2. Vérifiez si l'interface est active. Si l'interface n'est pas activée, utilisez la commande no shutdown pour activer l'interface.

   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. Assurez-vous que l’encapsulation est PPP. Si l’interface n’utilise pas PPP, utilisez la commande encapsulation ppp en mode de configuration d’interface pour la corriger.

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

4. Vérifiez si le bouclage est défini. Le bouclage doit être défini uniquement à des fins de test. Utilisez la commande no loopback pour supprimer les boucles.

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

5. Mettez le routeur hors tension puis sous tension.

6. Si le problème persiste, contactez votre fournisseur de services ou le centre d'assistance technique Cisco

Dépannage d'un PRI

Lors du dépannage d'un PRI, vous devez vérifier si le T1 fonctionne correctement aux deux extrémités. Si des problèmes de couche 1 ont été résolus, comme décrit ci-dessus, considérez les problèmes de couche 2 et de couche 3.

Dépannage à l’aide de la commande show isdn status

La commande show isdn status permet d'afficher un instantané de toutes les interfaces RNIS. Il affiche l'état des couches 1, 2 et 3.

1. Vérifiez que la couche 1 est active.

   L’état de la couche 1 doit toujours indiquer ACTIVE, sauf si la T1 est en panne. Si show isdn status indique que la couche 1 est DÉSACTIVÉE, il y a un problème de connectivité physique sur la ligne T1. Reportez-vous à la section « Le contrôleur T1 est-il arrêté ? »

   Vérifiez également que T1 n'est pas désactivé administrativement. Utilisez la commande no shutdown pour activer le contrôleur T1.

2. Vérifier si l'état de la couche 2 est MULTIPLE_FRAME_ESTABLISHED

L'état de couche 2 souhaité est Multiple_Frame_Etabli, ce qui indique que nous échangeons des trames de couche 2 et que nous avons terminé l'initialisation de la couche 2.

Si la couche 2 n'est pas Multiple_Frame_Étabhed , utilisez la commande EXEC show controller t1 pour diagnostiquer le problème. Reportez-vous à la section Dépannage à l'aide de la section show controller t1 Command de ce chapitre.

Comme la commande show isdn status est un instantané de l'état actuel, il est possible que la couche 2 rebondisse et s'arrête malgré l'indication Mulitple_Frame_Étabhed. Utilisez debug isdn q921 pour vérifier que la couche 2 est stable.

La commande debug isdn q921 affiche les procédures d'accès de couche liaison de données (couche 2) qui se déroulent au niveau du routeur sur le canal D.

Assurez-vous que vous êtes configuré pour afficher les messages de débogage à l'aide de la commande logging console ou terminal monitor si nécessaire.

Remarque : dans un environnement de production, vérifiez que la journalisation de console est désactivée. Entrez la commande show logging. Si la journalisation est activée, le serveur d'accès peut se figer de façon intermittente dès que le port de console est surchargé de messages de journal. Entrez la commande no logging console.

Remarque : Si debug isdn q921 est activé et que vous ne recevez aucune sortie de débogage, appelez ou réinitialisez le contrôleur pour obtenir les sorties de débogage.

1. Vérifiez que la couche 2 est stable.

   Vous devez observer les sorties de débogage des messages indiquant que le service ne rebondit pas et ne s'arrête pas. Si vous voyez les types suivants de sorties de débogage, la ligne n'est pas stable.

   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 couche 2 ne semble pas stable, reportez-vous à la section Dépannage des événements d'erreur T1, plus haut dans ce chapitre.

2. Vérifiez que vous ne voyez que des messages SAPI dans les deux côtés transmission (TX) et réception (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. Vérifiez que les messages SABME ne s'affichent pas, ce qui indique que la couche 2 tente de se réinitialiser. Ceci est généralement observé lorsque nous transmettons des requêtes d'interrogation (RR) et que nous n'obtenons pas de réponse du commutateur (RRf) ou vice versa. Voici des exemples de messages 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

   Si vous voyez des messages SABME, utilisez la commande show running-config pour voir si le type de commutateur RNIS et les intervalles de temps du groupe PRI sont configurés correctement. Contactez votre fournisseur de services pour connaître les valeurs correctes.

   Pour modifier le type de commutateur RNIS et le groupe 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. Vérifiez que le canal D est actif à l'aide de la commande show interfaces serial x:23.

   Si le canal D n'est pas actif, utilisez la commande no shutdown pour l'activer :

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

5. Vérifiez si l’encapsulation est PPP. Sinon, utilisez la commande encapsulation ppp pour définir l'encapsulation.

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

6. Vérifiez si l'interface est en mode bouclage. Pour un fonctionnement normal, l'interface ne doit pas être en mode bouclage.

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

7. Mettez le routeur hors tension puis sous tension.

8. Si le problème persiste, contactez votre fournisseur de services ou le centre d'assistance technique Cisco.

Exécution du test de bouclage matériel

Le test de bouclage matériel peut être utilisé pour vérifier si le routeur présente des défaillances. Si un routeur passe un test de bouclage matériel avec connecteur avec succès, c'est que le problème se situe à un autre endroit sur la ligne.

Créer un connecteur de bouclage :

Suivez ces étapes pour créer une fiche de bouclage.

1. Utilisez des coupe-fils pour couper un câble RJ-45 ou RJ-48 fonctionnel de sorte qu'il y ait cinq pouces de câble et que le connecteur y soit connecté.

2. Dénudez les fils.

3. Tourner les fils des broches 1 et 4 ensemble.

4. Tourner ensemble les fils des broches 2 et 5.

Les broches d'une prise RJ-45/48 sont numérotées de 1 à 8. La broche 1 est la broche la plus à gauche lorsque vous regardez la prise avec les broches métalliques qui vous font face.

Exécution du test de boucle locale

Procédez comme suit pour effectuer le test de la fiche de bouclage.

1. Insérez la fiche dans le port T1 en question.

2. Enregistrez la configuration de votre routeur à l'aide de la commande write memory.

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

3. Définir l’encapsulation sur 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. Utilisez la commande show running-config pour voir si l'interface possède une adresse IP.

   Si l'interface ne possède pas d'adresse IP, obtenez une adresse unique et affectez-la à l'interface avec le masque de sous-réseau 255.255.255.0.

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

5. Effacez les compteurs d'interface à l'aide de la commande clear counters.

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

6. Effectuez le test ping étendu comme décrit dans la section Utilisation des tests ping étendus, plus haut dans ce chapitre.

Dépannage de E1

Cette section décrit les techniques et procédures de dépannage des circuits E1 pour les clients commutés.

Dépannage à l'aide de la commande show controller e1

Cette commande affiche l'état du contrôleur spécifique au matériel du contrôleur. Les informations affichées sont généralement utiles pour les tâches de diagnostic effectuées uniquement par le personnel d'assistance technique.

Le NMP ou le MIP peut interroger les cartes de ports pour déterminer leur état actuel. Exécutez une commande show controller e1 pour afficher des statistiques sur la liaison E1. Si vous spécifiez un emplacement et un numéro de port, des statistiques s'affichent pour chaque période de 15 minutes.

La commande EXEC show controller e1 fournit des informations permettant de résoudre logiquement les problèmes de couche physique et de couche liaison de données. Cette section décrit comment dépanner logiquement à l'aide de la commande show controller e1.

La plupart des erreurs E1 sont causées par des lignes mal configurées. Assurez-vous que l'encodage de ligne, le tramage, la source d'horloge et la terminaison de ligne (symétrique ou asymétrique) sont configurés conformément aux recommandations du fournisseur de services.

show controller e1 Conditions

Le contrôleur E1 peut se trouver dans l'un des trois états suivants.

• Administrativement inactif

• Vers le bas

• Monter

Le contrôleur E1 est-il désactivé administrativement ?

Le contrôleur est désactivé par l'administrateur lorsqu'il a été arrêté manuellement. Vous devez redémarrer le contrôleur pour corriger cette erreur.

1. Passez en mode enable.

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

2. Entrez le mode de configuration globale .

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

3. Passez en mode de configuration du contrôleur.

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

4. Redémarrer le contrôleur.

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

La mise en ligne est-elle terminée ?

Si la ligne E1 n'est pas active, vérifiez que la configuration de la ligne est correcte et correspond aux paramètres de l'extrémité distante.

1. Vérifiez le tramage de la ligne et de l'extrémité distante. Pour les lignes E1, le tramage est CRC4 ou noCRC4

2. Vérifiez l'écodage de la ligne et de l'extrémité distante. La codages de ligne est AMI ou HDB3.

3. Vérifiez si la terminaison de la ligne est définie sur symétrique ou asymétrique (75 ohms ou 120 ohms).

Consultez votre fournisseur de services pour plus d'informations sur les paramètres corrects. Apportez les modifications nécessaires aux périphériques finaux locaux ou distants.

Si le contrôleur et la ligne E1 ne sont pas activés, vérifiez si l'un des messages suivants apparaît dans la sortie EXEC show controller e1 :

• Le récepteur a perdu la trame

• Le récepteur a une perte de signal

Si le récepteur E1 a perdu la trame :

Suivez ces étapes si le récepteur E1 perd de la trame.

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Vous pouvez vérifier le format de tramage du contrôleur à partir de la configuration en cours ou de la sortie de commande show controller e1.

   Pour modifier le format de tramage, utilisez le tramage {CRC4 | no CRC4} en mode de configuration du contrôleur, comme indiqué ci-dessous :

   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. Essayez l'autre format de tramage pour voir si l'alarme s'efface.

   Si cela ne résout pas le problème, reportez-vous à la section « If E1 Receiver Has Loss of Signal » ci-dessous.

3. Vérifiez le format de trame sur l'extrémité distante.

4. Vérifiez l'écrêtage de ligne sur l'extrémité distante.

Si le récepteur E1 a perdu le signal :

Suivez ces étapes si le récepteur E1 est en perte de signal

1. Assurez-vous que le câble entre le port d'interface et l'équipement du fournisseur de services E1 (ou l'équipement de terminal E1) est correctement connecté. Vérifiez si le câble est branché sur les ports appropriés. Corrigez les connexions des câbles au besoin.

2. Vérifiez l'intégrité des câbles. Recherchez des pauses ou d’autres anomalies physiques dans le câble. Vérifiez que les brochages sont correctement définis. Si nécessaire, remplacez le câble.

3. Vérifiez les connecteurs du câble. Une inversion des paires de transmission et de réception ou une paire de réception ouverte peut provoquer des erreurs. Définissez la paire de réception sur les lignes 1 et 2. Définissez la paire de transmission sur les lignes 4 et 5.

   Les broches d'une prise RJ-48 sont numérotées de 1 à 8. La broche 1 est la broche la plus à gauche lorsque vous regardez la prise avec les broches métalliques qui vous font face. Reportez-vous à la figure suivante pour plus d'informations.

   Figure 15-11 : Câble RJ-45

   

4. Essayez d'utiliser un câble à paires inversées.

5. Vérifiez s'il y a des erreurs de bloc de bout en bout. Si c'est le cas, le problème se pose avec le prospect de réception sur l'extrémité locale. Contactez le TAC pour obtenir de l'aide.

Exécutez la commande EXEC show controller e1 après chaque étape pour vérifier si le contrôleur présente des erreurs.

Si la ligne est en mode bouclage :

Vérifiez si la ligne est en mode bouclage à partir de la sortie show controller e1. Une ligne doit être en mode bouclage uniquement à des fins de test.

Pour désactiver le bouclage, utilisez la commande no loopback en mode de configuration du contrôleur, comme indiqué ci-dessous :

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

Si le contrôleur affiche des alarmes :

Vérifiez la sortie de la commande show controller pour voir s'il y a des alarmes affichées par le contrôleur.

Nous allons maintenant discuter des différentes alarmes et de la procédure nécessaire pour les corriger.

Le Récepteur (Rx) A Une Alarme À Distance :

Une alarme à distance reçue signifie qu'une alarme se produit sur la ligne en amont de l'équipement connecté au port.

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Si ce n'est pas le cas, modifiez le format de trame sur le contrôleur pour qu'il corresponde à celui de la ligne.

2. Vérifiez le paramètre de codage de ligne sur l'équipement distant. Communiquez avec votre fournisseur de services pour obtenir la configuration appropriée. Corrigez les erreurs de configuration si nécessaire.

3. Insérez un câble externe de rebouclage dans le port. Pour créer une fiche de bouclage, reportez-vous à la section « Exécution du test de la fiche de bouclage matérielle », plus haut dans le chapitre.

4. Vérifiez s'il y a des alarmes. Si aucune alarme ne s'affiche, le matériel local est probablement en bon état. Dans ce cas :

   1. Vérifiez le câblage. Pour plus d'informations, reportez-vous à la section « If E1 Receiver Has Loss of Signal ».

   2. Vérifiez les paramètres de l’extrémité distante et vérifiez qu’ils correspondent à vos paramètres de port.

   3. Si le problème persiste, communiquez avec votre fournisseur de services.

5. Retirez la fiche de bouclage et reconnectez votre ligne E1.

6. Vérifiez le câblage. Pour plus d'informations, reportez-vous à la section « If E1 Receiver Has Loss of Signal ».

7. Mettez le routeur hors tension puis sous tension.

8. Branchez la ligne E1 à un autre port. Configurez le port avec les mêmes paramètres que ceux de la ligne. Si le problème ne persiste pas, la défaillance se situe sur le port unique :

   1. Rebranchez la ligne E1 au port d’origine.

   2. Passez à la section Dépannage des événements d'erreur E1.

      Si le problème persiste, alors :

9. Effectuer un test de boucle matérielle comme décrit à la section « Exécution du test de boucle locale du matériel »

10. Remplacez la carte de contrôleur E1.

11. Passez à la section Dépannage des événements d'erreur E1.

Émetteur envoyant une alarme à distance (rouge) :

Une alarme rouge est déclarée lorsque l'unité CSU ne peut pas se synchroniser avec le modèle de tramage sur la ligne E1.

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Si ce n'est pas le cas, modifiez le format de trame sur le contrôleur pour qu'il corresponde à celui de la ligne.

2. Vérifiez les paramètres de l’extrémité distante et vérifiez qu’ils correspondent à vos paramètres de port.

3. Insérez un câble externe de rebouclage dans le port. Pour créer une fiche de bouclage, reportez-vous à la section « Exécution du test de la fiche de bouclage matérielle », plus haut dans le chapitre.

4. Vérifiez s'il y a des alarmes. Si aucune alarme ne s'affiche, le matériel local est probablement en bon état. Dans ce cas :

   1. Vérifiez le câblage. Pour plus d'informations, reportez-vous à la section « If E1 Receiver Has Loss of Signal ».

   2. Si le problème persiste, communiquez avec votre fournisseur de services.

5. Branchez la ligne E1 à un autre port. Configurez le port avec les mêmes paramètres que ceux de la ligne. Si le problème ne persiste pas, la faute incombe au port unique.

   1. Rebranchez la ligne E1 au port d’origine.

   2. Passez à la section Dépannage des événements d'erreur E1.

      Si le problème persiste, alors :

6. Effectuez un test de boucle matérielle comme décrit dans la section « Exécution du test de boucle de bouclage matériel ».

7. Remplacez la carte de contrôleur E1.

8. Passez à la section Dépannage des événements d'erreur E1.

9. Contactez votre fournisseur de services.

Dépannage des événements d'erreur E1

La commande EXEC show controller e1 fournit des messages d'erreur pouvant être utilisés pour résoudre des problèmes. Nous allons maintenant discuter de plusieurs messages d'erreur et de la façon de corriger les erreurs.

Pour voir si les compteurs d'erreurs augmentent, exécutez la commande show controller e1 à plusieurs reprises. Notez les valeurs des compteurs pour l'intervalle actuel. Consultez votre fournisseur de services pour connaître les paramètres de tramage et de codages.

Le compteur de secondes de glissement augmente :

La présence de bordures sur les lignes E1 indique un problème de synchronisation. Le fournisseur E1 (Telco) fournira la synchronisation à laquelle l'équipement client (CPE) doit être synchronisé.

1. Vérifiez que la source d'horloge provient du réseau. Pour cela, il suffit de rechercher Clock Source is Line Primary.

   Remarque : s'il existe plusieurs E1 dans un serveur d'accès, un seul peut être le principal, tandis que les autres E1 dérivent l'horloge du principal. Dans ce cas, vérifiez que la ligne E1 désignée comme source d'horloge principale est correctement configurée.

2. Définissez correctement la source d'horloge E1 à partir du mode de configuration du contrôleur.

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

Le compteur de pertes de trames en secondes augmente :

Suivez ces étapes lorsque le compteur de secondes de perte de trame augmente :

1. Vérifiez si le format de tramage configuré sur le port correspond au format de tramage de la ligne. Vous pouvez vérifier cela en recherchant la valeur de trame {CRC4|no CRC4} dans la sortie show controller e1.

2. Pour modifier le format de tramage, utilisez le tramage {CRC4 | no CRC4} en mode de configuration du contrôleur, comme indiqué ci-dessous :

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

Les violations de code de ligne augmentent :

Suivez ces étapes lorsque les violations de code de ligne augmentent.

1. Vérifiez si l'écrêtage de ligne configuré sur le port correspond au format de trame de la ligne. Vous pouvez vérifier cela en recherchant le code de ligne {AMI/HDB3} dans la sortie show controller e1.

2. Pour modifier l'écrêtage de ligne, utilisez le code de ligne {ami | hdb3} en mode de configuration du contrôleur, comme indiqué ci-dessous :

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

Vérification de la configuration correcte du type de commutateur RNIS et du groupe PRI

Utilisez la commande show running-config pour vérifier si le type de commutateur RNIS et les intervalles de temps du groupe PRI sont configurés correctement. Contactez votre fournisseur de services pour connaître les valeurs correctes.

Pour modifier le type de commutateur RNIS et le groupe 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

Vérification du canal de signalisation

Si les compteurs d'erreur n'augmentent pas mais que le problème persiste, vérifiez que le canal de signalisation est actif et configuré correctement.

1. Exécutez la commande show interface serial x:15, où x doit être remplacé par le numéro d'interface.

2. Vérifiez si l'interface est active. Si l'interface n'est pas activée, utilisez la commande no shutdown pour activer l'interface.

   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. Assurez-vous que l’encapsulation est PPP. Si l’interface n’utilise pas PPP, utilisez la commande encapsulation ppp en mode de configuration d’interface pour la corriger.

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

4. Vérifiez si le bouclage est défini. Le bouclage doit être défini uniquement à des fins de test. Utilisez la commande no loopback pour supprimer les boucles.

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

5. Mettez le routeur hors tension puis sous tension.

6. Si le problème persiste, contactez votre fournisseur de services ou le centre d'assistance technique Cisco.

Dépannage d'un PRI

Lors du dépannage d'un PRI, vous devez déterminer si l'E1 fonctionne correctement aux deux extrémités. Si les problèmes de couche 1 ont été résolus comme décrit ci-dessus, considérez les problèmes de couche 2 et de couche 3.

Dépannage à l’aide de la commande show isdn status

La commande show isdn status permet d'afficher un instantané de toutes les interfaces RNIS. Il affiche l'état des couches 1, 2 et 3.

1. Vérifiez que la couche 1 est active.

   L’état de la couche 1 doit toujours indiquer ACTIVE, sauf si E1 est en panne.

   Si show isdn status indique que la couche 1 est DÉSACTIVÉE, il y a un problème de connectivité physique sur la ligne E1. Reportez-vous à la section « Le contrôleur E1 est-il désactivé administrativement ? »

   Vérifiez également que l'E1 n'est pas désactivé administrativement. Utilisez la commande no shutdown pour activer le contrôleur E1.

2. Vérifiez si l'état de la couche 2 est MULTIPLE_FRAME_ESTABLISHED.

L’état de couche 2 souhaité est Multiple_Frame_Etabli, ce qui indique que le protocole de démarrage entre le commutateur RNIS et le périphérique final a été établi et que nous échangeons des trames de couche 2.

Si la couche 2 n'est pas Multiple_Frame_Étabhed, utilisez la commande EXEC show controller e1 pour diagnostiquer le problème. Reportez-vous à la section Dépannage à l'aide de la commande show controller e1 dans ce chapitre et à la section Dépannage des événements d'erreur E1.

Comme show isdn status est un instantané de l'état actuel, il est possible que la couche 2 rebondisse et s'arrête malgré l'indication Mulitple_Frame_Étabhed. Utilisez la commande debug isdn q921 pour vérifier que la couche 2 est stable.

Utilisation de debug q921

La commande debug isdn q921 affiche les procédures d'accès de couche liaison de données (couche 2) qui se déroulent au niveau du routeur sur le canal D.

Assurez-vous que vous êtes configuré pour afficher les messages de débogage à l'aide de la commande logging console ou terminal monitor si nécessaire.

Remarque : dans un environnement de production, vérifiez que la journalisation de console est désactivée. Entrez la commande show logging. Si la journalisation est activée, le serveur d'accès peut se figer de façon intermittente dès que le port de console est surchargé de messages de journal. Entrez la commande no logging console.

Remarque : Si debug isdn q921 est activé et que vous ne recevez aucune sortie de débogage, appelez ou réinitialisez le contrôleur pour obtenir les sorties de débogage.

1. Vérifiez que la couche 2 est stable. Vous devez observer les sorties de débogage des messages indiquant que le service ne rebondit pas et ne s'arrête pas. Si vous voyez les types suivants de sorties de débogage, la ligne n'est pas stable.

   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
   
   

   Si la couche 2 ne semble pas stable, reportez-vous à Dépannage des événements d'erreur E1, plus haut dans ce chapitre.

2. Vérifiez que vous ne voyez que des messages SAPI dans les deux côtés transmission (TX) et réception (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. Vérifiez que les messages SABME ne s'affichent pas, ce qui indique que la couche 2 tente de se réinitialiser. Ceci est généralement observé lorsque nous transmettons des requêtes d'interrogation (RR) et que nous n'obtenons pas de réponse du commutateur (RRf) ou vice versa. Voici des exemples de messages SABME. Nous devons obtenir une réponse du commutateur RNIS pour nos messages SABME (trame UA reçue).

   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

   Si vous voyez des messages SABME, utilisez la commande show running-config pour vérifier si le type de commutateur RNIS et les intervalles de temps du groupe PRI sont configurés correctement. Contactez votre fournisseur de services pour connaître les valeurs correctes.

   Pour modifier le type de commutateur RNIS et le groupe 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. Vérifiez que le canal D est actif à l'aide de la commande show interfaces serial x:15.

   Si le canal D n'est pas actif, utilisez la commande no shutdown pour le faire apparaître :

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

5. Vérifiez si l’encapsulation est PPP. Si ce n'est pas le cas, utilisez la commande encapsulation ppp pour définir l'encapsulation.

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

6. Vérifiez si l'interface est en mode bouclage. Pour un fonctionnement normal, l'interface ne doit pas être en mode bouclage.

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

7. Mettez le routeur hors tension puis sous tension.

8. Si le problème persiste, contactez votre fournisseur de services ou le centre d'assistance technique Cisco.

Informations connexes

• Support technique - Cisco Systems

Historique de révision