Dépannage de connectivité d'accès commuté – appel initié par DDR IOS

Options de téléchargement

  • PDF     (217.2 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (95.9 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (104.2 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:9 juillet 2007
ID du document:14954

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document fournit des méthodes de dépannage de différents types de connexions de numérotation et n'est pas destiné à être lu du début à la fin. La structure est conçue pour permettre au lecteur de passer aux sections d'intérêt, qui sont chacune des variations du thème de dépannage global d'un cas spécifique.

Conditions préalables

Conditions requises

Ce document couvre trois grands scénarios ; avant de commencer le dépannage, déterminez le type d'appel tenté et accédez à cette section :

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.

Historique

La connexion commutée est simplement l'application du réseau téléphonique public commuté (RTPC) qui transporte les données au nom de l'utilisateur final. Il s’agit d’un équipement client (CPE) qui envoie au commutateur téléphonique un numéro de téléphone vers lequel diriger une connexion. Les AS3600, AS5200, AS5300 et AS5800 sont tous des exemples de routeurs capables d'exécuter une interface PRI (Primary Rate Interface) avec des banques de modems numériques. L’AS2511, en revanche, est un exemple de routeur qui communique avec des modems externes.

Le marché des opérateurs s'est considérablement développé et le marché exige désormais des densités de modems plus élevées. La réponse à ce besoin est un niveau plus élevé d'interopérabilité avec l'équipement de la compagnie de téléphone et le développement du modem numérique. Il s'agit d'un modem capable d'un accès numérique direct au RTPC. En conséquence, des modems CPE plus rapides ont été développés pour tirer parti de la clarté du signal dont jouissent les modems numériques. Le fait que les modems numériques se connectant au RTPC via une interface PRI ou BRI (Basic Rate Interface) puisse transmettre des données à plus de 53 000 en utilisant la norme de communication V.90 atteste du succès de l'idée.

Les premiers serveurs d'accès étaient les AS2509 et AS2511. L'AS2509 peut prendre en charge 8 connexions entrantes à l'aide de modems externes et l'AS2511 peut prendre en charge 16. L'AS5200 a été introduit avec 2 PRI et pourrait prendre en charge 48 utilisateurs utilisant des modems numériques, et représente un grand bond en avant en matière de technologie. Les densités de modems ont augmenté régulièrement avec l'AS5300 prenant en charge 4, puis 8 PRI. Enfin, l'AS5800 a été introduit pour répondre aux besoins des installations de classe opérateur qui doivent gérer des dizaines de T1 entrants et des centaines de connexions utilisateur.

Quelques technologies obsolètes méritent d'être mentionnées dans une discussion historique sur la technologie de numérotation. 56Kflex est une vieille norme de 56k (pré-V.90) proposée par Rockwell. Cisco prend en charge la version 1.1 de la norme 56Kflex sur ses modems internes, mais recommande de migrer les modems CPE vers V.90 dès que possible. Une autre technologie obsolète est l'AS5100. L'AS5100 était une coentreprise entre Cisco et un fabricant de modems. L'AS5100 a été créé pour augmenter la densité des modems grâce à l'utilisation de cartes quadruples. Il s'agissait d'un groupe d'AS2511 conçus comme des cartes insérées dans un fond de panier partagé par des cartes à quatre modems et une carte T1 double.

Conventions

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

Cisco IOS DDR lance l'appel

Alors que l'approche de dépannage des appels entrants commence en bas, le dépannage d'une connexion sortante commence en haut.

Le raisonnement général ressemble à ce qui suit :

  1. Le routage à établissement de connexion à la demande (DDR) lance-t-il un appel ? (Une réponse oui passe à la question suivante.)

  2. S'il s'agit d'un modem asynchrone, les scripts de discussion émettent-ils les commandes attendues ?

  3. L'appel est-il transmis au RTPC ?

  4. L'extrémité distante répond-elle à l'appel ?

  5. L'appel est-il terminé ?

  6. Les données transitent-elles sur la liaison ?

  7. La session est-elle établie ? (PPP ou terminal)

Pour savoir si le numéroteur tente d'appeler sa destination distante, utilisez la commande debug dialer events. Des informations plus détaillées peuvent être obtenues à partir du paquet debug dialer, mais la commande debug dialer packet est gourmande en ressources et ne doit pas être utilisée sur un système occupé qui dispose de plusieurs interfaces de numérotation.

La ligne suivante de la sortie des événements de numérotation de débogage pour un paquet IP répertorie le nom de l'interface DDR et les adresses source et de destination du paquet : 

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

Si le trafic n'initie pas de tentative de numérotation, la raison la plus courante est une configuration incorrecte (soit l'une des définitions de trafic intéressantes, l'état de l'interface de numérotation, soit le routage).

Tableau 1 : Le trafic n'initie pas de tentative de numérotation

Causes possibles Actions suggérées
Définitions de « trafic intéressant » manquantes ou incorrectes
  1. À l'aide de la commande show running-config, assurez-vous que l'interface est configurée avec un groupe de numérotation et qu'il existe une liste de numérotation globale configurée avec un numéro correspondant.
  2. Assurez-vous que la commande dialer-list est configurée pour autoriser un protocole entier ou pour autoriser le trafic correspondant à une liste d'accès
  3. Vérifiez que la liste d'accès déclare intéressants les paquets circulant sur la liaison. Un test utile consiste à utiliser la commande d'exécution privilégiée debug ip packet [list number] en utilisant le numéro de la liste d'accès pertinente. Essayez ensuite d’envoyer une requête ping ou d’envoyer du trafic via la liaison. Si les filtres de trafic intéressants ont été correctement définis, vous verrez les paquets dans la sortie de débogage. S'il n'y a pas de sortie de débogage de ce test, la liste d'accès ne correspond pas aux paquets.
État de l'interface Utilisez la commande show interfaces <interface name> pour vous assurer que l'interface est à l'état « up/up (spoofing)« .
  • Interface en mode veille
Une autre interface (principale) du routeur a été configurée pour utiliser l'interface de numérotation comme interface de sauvegarde. En outre, l'interface principale n'est pas en état « down/down », ce qui est nécessaire pour sortir l'interface de numérotation du mode veille. En outre, un délai de sauvegarde doit être configuré sur l'interface principale, sinon la commande d'interface de sauvegarde ne sera jamais appliquée. Pour vérifier que l'interface de numérotation passe de « veille » à « up/up (spoofing)« , il est généralement nécessaire de retirer le câble de l'interface principale. L'arrêt de l'interface principale à l'aide de la commande de configuration shutdown ne placera pas l'interface principale dans « down/down », mais la place dans « administratically down » ? pas la même chose. En outre, si la connexion principale est via Frame Relay, la configuration Frame Relay doit être effectuée sur une sous-interface série point à point et la compagnie de téléphone doit passer le bit « Actif ». Cette pratique est également appelée « interface de gestion locale de bout en bout (LMI)« .
  • L'interface est « administrativement désactivée »
L'interface de numérotation a été configurée avec la commande shutdown. Il s’agit également de l’état par défaut de toute interface lorsqu’un routeur Cisco est amorcé pour la toute première fois. Utilisez la commande de configuration d'interface no shutdown pour supprimer cet obstacle.
Routage incorrect Exécutez la commande exec show ip route [a.b.c.d], où a.b.c.d est l'adresse de l'interface de numérotation du routeur distant. Si ip unnumbered est utilisé sur le routeur distant, utilisez l'adresse de l'interface répertoriée dans la commande ip unnumbered. Le résultat doit afficher une route vers l'adresse distante via l'interface de numérotation. S'il n'y a pas de route, assurez-vous que des routes statiques ou flottantes ont été configurées en examinant le résultat de show running-config. S’il existe une route via une interface autre que l’interface de numérotation, cela signifie que DDR est utilisé comme sauvegarde. Examinez la configuration du routeur pour vous assurer que des routes statiques ou flottantes ont été configurées. La meilleure façon de tester le routage, dans ce cas, est de désactiver la connexion principale et d'exécuter la commande show ip route [a.b.c.d] pour vérifier que la route appropriée a été installée dans la table de routage.

Remarque : si vous tentez de le faire lors d'opérations en direct sur le réseau, un événement de numérotation peut être déclenché. Ce type de test est le mieux effectué lors des cycles de maintenance programmés.

Passer l'appel

Si le routage et les filtres de trafic intéressants sont corrects, un appel doit être lancé. Ceci peut être vu à l'aide des événements de numérotation de débogage : 

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

Si la cause de numérotation est visible mais qu'aucune tentative de numérotation n'est effectuée, la raison habituelle est une carte de numérotation ou un profil de numérotation mal configuré.

Tableau 2 : Appel non passé

Problème possible Actions suggérées
Carte de numérotation mal configurée Utilisez la commande show running-config pour vous assurer que l'interface de numérotation est configurée avec au moins une instruction dialer map qui pointe vers l'adresse de protocole et le numéro appelé du site distant.
Profil de numérotation mal configuré Utilisez la commande show running-config pour vous assurer que l'interface de numérotation est configurée avec une commande dialer pool X et qu'une interface de numérotation sur le routeur est configurée avec un membre de pool de numérotation correspondant X. Si les profils de numérotation ne sont pas correctement configurés, un message de débogage peut s'afficher comme : 
Dialer1: Can't place call, no dialer pool set
Vérifiez qu'une chaîne de numérotation est configurée.

Ensuite, identifiez le type de support utilisé :

DDR de modem asynchrone externe

  1. Pour identifier un DDR de modem asynchrone externe, utilisez les commandes suivantes, puis essayez de passer un appel : 

    router# debug modem
router# debug chat line

  2. Pour les appels par modem, un script de conversation doit s'exécuter pour que l'appel puisse continuer. Pour le DDR basé sur une carte de numérotation, le script de conversation est appelé par le paramètre de script de modem dans une commande de mappage de numérotation. Si le DDR est basé sur le profil de numérotation, cela est accompli par la commande script dialer, configurée sur la ligne TTY. Les deux méthodes reposent sur un script de conversation existant dans la configuration globale du routeur, par exemple : 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Dans les deux cas, la commande permettant d'afficher l'activité du script de discussion est debug chat. Si la chaîne de numérotation (c'est-à-dire le numéro de téléphone) utilisée dans la commande dialer map ou dialer string était 5551212, la sortie de débogage ressemblerait à ceci : 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Assurez-vous que le script de conversation tente l'appel attendu (c'est-à-dire le bon numéro) en fonction de la chaîne d'envoi. Si le script de conversation ne tente pas de passer l'appel attendu, vérifiez la configuration du script de conversation. Utilisez la commande start-chat à l'invite exec pour lancer le script de conversation manuellement.

  4. Voir « Délai d'attente : CONNECT » peut décrire plusieurs possibilités différentes :

    • Possibilité 1 : Le modem local ne passe pas l'appel. Vérifiez que le modem peut passer un appel en effectuant une connexion Telnet inverse au modem et en lançant manuellement une numérotation. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est passé par le modem d'origine en appelant manuellement un numéro local à l'aide de la commande ATDT <number> et en écoutant la sonnerie.

    • Possibilité 2 : Le modem distant ne répond pas. Testez-le en composant le modem distant avec un téléphone POTS ordinaire. Essayez ceci:

      1. Vérifiez que le numéro de téléphone appelé est correct. Utilisez un combiné pour appeler le numéro de réception. Veillez à utiliser le même câble sur le mur que celui utilisé par le modem. Si un appel manuel peut atteindre le modem asynchrone de réception, le modem d'origine peut ne pas fonctionner correctement. Vérifiez le modem et remplacez-le si nécessaire.

      2. Si un appel manuel ne parvient pas à atteindre le modem asynchrone de réponse, modifiez les câbles téléphoniques sur le modem récepteur et essayez un téléphone normal sur la ligne du modem récepteur. Si l'appel peut être reçu par le téléphone normal, il y a probablement un problème avec le modem récepteur.

      3. Si l'appel manuel n'est toujours pas en mesure d'atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (connue) dans l'installation de réception. Si cela se connecte correctement, demandez à l'opérateur téléphonique de vérifier la ligne téléphonique qui se connecte au modem récepteur.

      4. S'il s'agit d'un appel longue distance, demandez à la partie d'origine d'essayer un autre numéro longue distance (connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut pas être provisionnée pour recevoir des appels longue distance. Si la ligne d'origine ne peut pas atteindre d'autres numéros interurbains, elle n'est peut-être pas activée. Essayez les codes 1010 pour différentes compagnies interurbains.

      5. Enfin, essayez un autre numéro local (connu) de la ligne d'origine. Si la connexion échoue toujours, demandez à l’opérateur téléphonique de vérifier la ligne d’origine.

    • Possibilité 3 : Le numéro composé est incorrect. Vérifiez le numéro en le composant manuellement. Corrigez la configuration, si nécessaire.

    • Possibilité 4 : La formation du modem prend trop de temps ou la valeur TIMEOUT est trop faible. Essayez d'augmenter la valeur TIMEOUT dans la commande chat-script. Si le délai d’attente est déjà de 60 secondes ou plus, il peut y avoir un problème de câble entre le modem et l’ETTD auquel il est connecté. Les échecs de formation peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour accéder au bas d'un problème de modem individuel, accédez à l'invite AT à l'invite du modem d'origine avec telnet inverse. Si possible, accédez également à l'invite AT du modem récepteur. La plupart des modems indiquent une sonnerie à la session de terminal connectée à leur connexion ETTD. Utilisez ATM1 pour que le modem envoie des sons à son haut-parleur afin que les utilisateurs de chaque extrémité puissent entendre ce qui se passe sur la ligne.

      La musique a-t-elle du bruit ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'entraînent pas, appelez le numéro et écoutez le message statique. Il peut y avoir d'autres facteurs qui interférent avec la montée des trains. Inverse telnet au modem asynchrone et débogage.

  5. Si tout fonctionne correctement et que vous ne pouvez toujours pas vous connecter au DDR de votre modem asynchrone CAS, essayez le débogage PPP. Utilisez les commandes suivantes : 

    router# debug ppp negotiation
     router# debug ppp authentication

    Si le script de conversation s'exécute correctement, les modems sont connectés. Consultez la section "Dépannage du protocole PPP" du chapitre 17 du Guide de dépannage de l'interréseau pour connaître l'étape suivante du dépannage de la connexion.

DDR de modem asynchrone CAS T1/E1

  1. Pour identifier un DDR de modem asynchrone CAS T1/E1, utilisez les commandes suivantes, puis essayez de passer un appel :

    warning Avertissement :  L'exécution de débogages sur un système occupé peut faire planter le routeur en surchargeant le processeur ou en surexécutant la mémoire tampon de la console ! 

    router# debug modem
router# debug chat or debug chat line n

router# debug modem csm
router# debug cas

    Remarque : La commande debug cas est disponible sur les plates-formes Cisco AS5200 et AS5300 exécutant Cisco IOS ? Logiciel version 12.0(7)T et ultérieure. Dans les versions antérieures d'IOS, la commande service internal doit être entrée dans le niveau principal de la configuration du routeur et modem-mgmt csm debug-rbs doit être entrée à l'invite exec. Le débogage sur le Cisco AS5800 nécessite une connexion à la carte réseau. (Utilisez modem-mgmt csm no-debug-rbs pour désactiver le débogage.)

  2. Pour les appels par modem, un script de conversation doit s'exécuter pour que l'appel puisse continuer. Pour le DDR basé sur une carte de numérotation, le script de conversation est appelé par le paramètre de script de modem dans une commande de mappage de numérotation. Si le DDR est basé sur le profil de numérotation, cela est accompli par la commande script dialer, configurée sur la ligne TTY. Les deux utilisations reposent sur un script de conversation existant dans la configuration globale du routeur, tel que : 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Dans les deux cas, la commande permettant d'afficher l'activité du script de discussion est debug chat. Si la chaîne de numérotation (c'est-à-dire le numéro de téléphone) utilisée dans la commande dialer map ou dialer string était 5551212, la sortie de débogage ressemblerait à ceci : 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Assurez-vous que le script de conversation tente l'appel attendu (c'est-à-dire le bon numéro) en fonction de la chaîne d'envoi. Si le script de conversation ne tente pas de passer l'appel attendu, vérifiez la configuration du script de conversation. Utilisez la commande start-chat à l'invite exec pour lancer le script de conversation manuellement.

  4. Voir « Délai d'attente : CONNECT » peut décrire plusieurs possibilités différentes :

    • Possibilité 1 : Le modem local ne passe pas l'appel. Vérifiez que le modem peut passer un appel en effectuant une connexion Telnet inverse avec le modem et en lançant manuellement une numérotation. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est passé par le modem en appelant manuellement un numéro local à l'aide de la commande ATDT<number> et en écoutant la sonnerie.

      Pour les appels sortants via CAS T1 ou E1 et les modems numériques intégrés, une grande partie du dépannage est similaire à d'autres dépannages DDR. Il en va de même pour les appels sortants par modem intégré sur une ligne PRI. Les fonctionnalités uniques impliquées dans un appel de cette manière nécessitent un débogage spécial en cas de défaillance d'un appel.

      En ce qui concerne les autres situations DDR, vous devez vous assurer qu'une tentative d'appel est requise. Utilisez les événements debug dialer à cette fin. Référez-vous à DDR IOS , plus haut dans cet article.

      Avant de pouvoir passer un appel, un modem doit être attribué à l'appel. Pour afficher ce processus et l'appel suivant, utilisez les commandes de débogage suivantes : 

      router# debug modem
router# debug modem csm
router# debug cas

      Remarque : La commande debug cas est apparue pour la première fois dans IOS version 12.0(7)T pour AS5200 et AS5300. Les versions antérieures d’IOS utilisent une commande de configuration système service interne avec la commande exec modem-mgmt debug rbs :

      Activation des débogages : 

      router#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#service internal 
router(config)#^Z 
router#modem-mgmt csm ? 
  debug-rbs     enable rbs debugging 
  no-debug-rbs  disable rbs debugging 
router#modem-mgmt csm debug-rbs 
router# 
neat msg at slot 0: debug-rbs is on 
neat msg at slot 0: special debug-rbs is on

      Désactivation des débogages :

      router#modem-mgmt csm no-debug-rbs 
neat msg at slot 0: debug-rbs is off

      Le débogage de ces informations sur un AS5800 nécessite une connexion à la carte de liaison. Voici un exemple d'appel sortant normal sur un serveur CAS T1 provisionné et configuré pour FXS-Ground-Start : 

      Mica Modem(1/0): Rcvd Dial String(5551111) 
[Modem receives digits from chat script]

CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_CHANNEL_LOCK at slot 1 and port 0 

CSM_PROC_OC4_DIALING: 
CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 

Mica Modem(1/0): Configure(0x1) 

Mica Modem(1/0): Configure(0x2) 

Mica Modem(1/0): Configure(0x5) 

Mica Modem(1/0): Call Setup 

neat msg at slot 0: (0/2): Tx RING_GROUND 

Mica Modem(1/0): State Transition to Call Setup 

neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
[Telco switch goes OFFHOOK]

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_START_TX_TONE at slot 1 and port 0 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 

neat msg at slot 0: (0/2): 
Tx LOOP_CLOSURE [Now the router goes OFFHOOK]

Mica Modem(1/0): Rcvd Tone detected(2) 

Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 

Mica Modem(1/0): Rcvd Digits Generated 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_CHANNEL_CONNECTED at slot 1 and port 0 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 

Mica Modem(1/0): Link Initiate 

Mica Modem(1/0): State Transition to Connect 

Mica Modem(1/0): State Transition to Link 

Mica Modem(1/0): State Transition to Trainup 

Mica Modem(1/0): State Transition to EC Negotiating 

Mica Modem(1/0): State Transition to Steady State 

Mica Modem(1/0): State Transition to Steady State Speedshifting 

Mica Modem(1/0): State Transition to Steady State

      Les débogages pour les T1 et E1 avec d'autres types de signalisation sont similaires.

      Si vous arrivez à ce point dans le débogage, cela signifie que les modems d'appel et de réponse ont été formés et connectés et que les protocoles de couche supérieure peuvent commencer à négocier. Si un modem est correctement alloué pour l'appel sortant mais que la connexion ne parvient pas à atteindre ce niveau, il faut examiner le T1. Utilisez la commande show controller t1/e1 pour vérifier que T1/E1 fonctionne. Reportez-vous à Dépannage des lignes série pour une explication de la sortie show controller. Si le T1/E1 ne fonctionne pas correctement, le dépannage T1/E1 est nécessaire.

    • Possibilité 2 : Le modem distant ne répond pas. Testez-le en composant le modem distant avec un téléphone ordinaire. Essayez ceci:

      1. Vérifiez que le numéro de téléphone appelé est correct. Utilisez un combiné pour appeler le numéro de réception.

      2. Assurez-vous qu'un appel manuel est en mesure d'atteindre le modem asynchrone de réponse. Si un appel manuel peut atteindre le modem asynchrone de réponse, il se peut que la ligne CAS ne soit pas configurée pour autoriser les appels vocaux sortants.

      3. Si un appel manuel ne parvient pas à atteindre le modem asynchrone de réponse, modifiez les câbles téléphoniques sur le modem récepteur et essayez un téléphone normal sur la ligne du modem récepteur. Si l'appel peut être reçu par le téléphone normal, il y a probablement un problème avec le modem récepteur.

      4. Si l'appel manuel n'est toujours pas en mesure d'atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (connue) dans l'installation de réception. Si cela se connecte, demandez à l'opérateur de téléphonie de vérifier la ligne téléphonique vers le modem récepteur.

      5. S'il s'agit d'un appel longue distance, demandez à la partie d'origine d'essayer un autre numéro longue distance (connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut pas être provisionnée pour recevoir des appels longue distance. Si la ligne d'origine (CAS) ne peut pas atteindre d'autres numéros d'interurbain, il se peut que l'interurbain ne soit pas activé. Essayez les codes 10-10 pour différentes compagnies interurbains.

      6. Enfin, essayez un autre numéro local (connu) de la ligne CAS d'origine. Si la connexion échoue toujours, demandez à telco de vérifier le CAS.

    • Possibilité 3 : Le numéro composé est incorrect. Vérifiez le numéro en le composant manuellement. Corrigez la configuration, si nécessaire.

    • Possibilité 4 : La formation du modem prend trop de temps ou la valeur TIMEOUT est trop faible. Essayez d'augmenter la valeur TIMEOUT dans la commande chat-script. Si le délai d’attente est déjà de 60 secondes ou plus, il peut y avoir un problème de câble entre le modem et l’ETTD auquel il est connecté. Les échecs de formation peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour accéder au bas d'un problème de modem individuel, accédez à l'invite AT à l'invite du modem d'origine avec telnet inverse. Si possible, utilisez la connexion Telnet inverse pour accéder également à l'invite AT du modem récepteur. Utilisez ATM1 pour que le modem envoie des sons à son haut-parleur afin que les utilisateurs de chaque extrémité puissent entendre ce qui se passe sur la ligne.

      La musique a-t-elle du bruit ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'entraînent pas, appelez le numéro et écoutez le message statique. Il peut y avoir d'autres facteurs qui interférent avec la montée des trains. Inverse telnet au modem asynchrone et débogage.

  5. Si tout fonctionne correctement et que vous ne pouvez toujours pas vous connecter au DDR de votre modem asynchrone CAS, essayez le débogage PPP. Si le script de discussion se termine correctement et que les débogages PPP indiquent une défaillance, consultez la section "Dépannage PPP" du Chapitre 17 du Guide de dépannage de l'interréseau.

DDR de modem asynchrone PRI

  1. Pour identifier un DDR de modem asynchrone PRI, utilisez les commandes suivantes, puis essayez de passer un appel :

    warning Avertissement :  L'exécution de débogages sur un système occupé peut faire planter le routeur en surchargeant le processeur ou en surexécutant la mémoire tampon de la console ! 

    router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug isdn
router# debug ppp negotiate
router# debug ppp authenticate

  2. Pour les appels par modem, un script de conversation doit s'exécuter pour que l'appel puisse continuer. Pour le DDR basé sur une carte de numérotation, le script de conversation est appelé par le paramètre de script de modem dans une commande de mappage de numérotation. Si le DDR est basé sur le profil de numérotation, cela est accompli par la commande script dialer, configurée sur la ligne TTY. Les deux méthodes reposent sur un script de conversation existant dans la configuration globale du routeur, par exemple : 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Dans les deux cas, la commande permettant d'afficher l'activité du script de discussion est debug chat. Si la chaîne de numérotation (numéro de téléphone) utilisée dans la commande dialer map ou dialer string était 5551212, la sortie de débogage ressemblerait à ceci : 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Assurez-vous que le script de conversation tente l'appel attendu (le bon numéro) en fonction de la chaîne d'envoi. Si le script de conversation ne tente pas de passer l'appel attendu, vérifiez la configuration du script de conversation. Utilisez la commande start-chat à l'invite exec pour lancer le script de conversation manuellement.

  4. Voir « Délai d'attente : CONNECT » peut décrire plusieurs possibilités différentes :

    • Possibilité 1 : Le modem local ne passe pas l'appel. Vérifiez que le modem peut passer un appel en effectuant une connexion Telnet inverse au modem et en lançant manuellement une numérotation. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est passé par le modem en appelant manuellement un numéro local à l'aide de la commande ATDT<number> et en écoutant la sonnerie. Si aucun appel ne sort, activez les débogages RNIS. En cas de première suspicion de défaillance RNIS sur un BRI, vérifiez toujours le résultat de show isdn status. Les éléments clés à noter sont que la couche 1 doit être active et la couche 2 doit être dans un état MULTIPLE_FRAME_ESTABLISHED. Reportez-vous au chapitre 16 du Guide de dépannage des interréseaux, "Interprétation de l'état RNIS" pour obtenir des informations sur la lecture de ce résultat, ainsi que des mesures correctives.

      Pour les appels RNIS sortants, debug isdn q931 et debug isdn events sont les meilleurs outils à utiliser. Heureusement, le débogage des appels sortants est très similaire au débogage des appels entrants. Un appel normalement réussi peut ressembler à ceci : 

      *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

      Notez que le message CONNECT est le principal indicateur de succès. Si aucun CONNECT n'est reçu, vous pouvez voir un message DISCONNECT ou RELEASE_COMP (version complète) suivi d'un code de cause : 

      *Mar 20 22:11:03.212: ISDN SE0:23: 
RX <-RELEASE_COMP pd = 8 callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

      La valeur de la cause indique deux choses :

      • Le deuxième octet de la valeur de 4 ou 6 octets indique le point du chemin d'appel de bout en bout à partir duquel DISCONNECT ou RELEASE_COMP a été reçu. Cela peut vous aider à localiser le problème.

      • Les troisième et quatrième octets indiquent la raison réelle de l'échec. Voir le tableau 9 pour la signification des différentes valeurs.

    • Possibilité 2 : Le modem distant ne répond pas. Testez-le en composant le modem distant avec un téléphone ordinaire. Essayez ceci:

      1. Vérifiez que le numéro de téléphone appelé est correct. Utilisez un combiné pour appeler le numéro de réception.

      2. Assurez-vous qu'un appel manuel est en mesure d'atteindre le modem asynchrone de réponse. Si un appel manuel peut atteindre le modem asynchrone de réponse, il se peut que la ligne BRI ne soit pas provisionnée pour autoriser les appels vocaux sortants.

      3. Si un appel manuel ne parvient pas à atteindre le modem asynchrone de réponse, modifiez les câbles téléphoniques sur le modem récepteur et essayez un téléphone normal sur la ligne du modem récepteur. Si l'appel peut être reçu par le téléphone normal, il y a probablement un problème avec le modem récepteur.

      4. Si l'appel manuel n'est toujours pas en mesure d'atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (connue) dans l'installation de réception. Si cela se connecte, demandez à l'opérateur de téléphonie de vérifier la ligne téléphonique vers le modem récepteur.

      5. S'il s'agit d'un appel longue distance, demandez à la partie d'origine d'essayer un autre numéro longue distance (connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut pas être provisionnée pour recevoir des appels longue distance. Si la ligne d'origine (BRI) ne peut pas atteindre d'autres numéros longue distance, elle n'est peut-être pas activée. Essayez les codes 1010 pour différentes sociétés longue distance.

      6. Enfin, essayez un autre numéro local (connu) de la ligne BRI d'origine. Si la connexion échoue toujours, demandez à l’opérateur téléphonique de vérifier l’accès de base (BRI).

    • Possibilité 3 : Le numéro composé est incorrect. Vérifiez le numéro en le composant manuellement. Corrigez la configuration, si nécessaire.

    • Possibilité 4 : La formation du modem prend trop de temps ou la valeur TIMEOUT est trop faible. Essayez d'augmenter la valeur TIMEOUT dans la commande chat-script. Si le délai d’attente est déjà de 60 secondes ou plus, il peut y avoir un problème de câble entre le modem et l’ETTD auquel il est connecté. Les échecs de formation peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour accéder au bas d'un problème de modem individuel, accédez à l'invite AT à l'invite du modem d'origine avec telnet inverse. Si possible, utilisez la connexion Telnet inverse pour accéder également à l'invite AT du modem récepteur. Utilisez ATM1 pour que le modem envoie des sons à son haut-parleur afin que les utilisateurs de chaque extrémité puissent entendre ce qui se passe sur la ligne.

      La musique a-t-elle du bruit ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'entraînent pas, appelez le numéro et écoutez le message statique. Il peut y avoir d'autres facteurs qui interférent avec la montée des trains. Inverse telnet au modem asynchrone et débogage.

  5. Si tout fonctionne correctement et que vous ne pouvez toujours pas vous connecter à votre DDR de modem asynchrone BRI, essayez le débogage PPP. Si le script de discussion se termine correctement et que les débogages PPP indiquent une défaillance, consultez la section "Dépannage PPP" du Chapitre 17 du Guide de dépannage de l'interréseau.

DDR modem asynchrone BRI

Cette fonctionnalité fonctionne uniquement sur la plate-forme Cisco 3640 à l'aide du logiciel Cisco IOS Version 12.0(3)T ou ultérieure. Il nécessite une révision matérielle ultérieure du module de réseau BRI. Cela ne fonctionne pas avec une carte d'interface WAN (WIC).

  1. Assurez-vous que le code de pays est correct avec la commande show modem. Utilisez les commandes suivantes, puis essayez de passer un appel :

    warning Avertissement :  L'exécution de débogages sur un système occupé peut faire planter le routeur en surchargeant le processeur ou en surexécutant la mémoire tampon de la console ! 

    router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug bri
router# debug ppp negotiate
router# debug ppp authenticate

  2. Pour les appels par modem, un script de conversation doit s'exécuter pour que l'appel puisse continuer. Pour le DDR basé sur une carte de numérotation, le script de conversation est appelé par le paramètre de script de modem dans une commande de mappage de numérotation. Si le DDR est basé sur le profil de numérotation, cela est accompli par la commande script dialer, configurée sur la ligne TTY. Les deux utilisations reposent sur un script de conversation existant dans la configuration globale du routeur, tel que : 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Dans les deux cas, la commande permettant d'afficher l'activité du script de discussion est debug chat. Si la chaîne de numérotation (numéro de téléphone) utilisée dans la commande dialer map ou dialer string était 5551212, la sortie de débogage ressemblerait à ceci : 

    CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Assurez-vous que le script de conversation tente l'appel attendu (le bon numéro) en fonction de la chaîne d'envoi. Si le script de conversation ne tente pas de passer l'appel attendu, vérifiez la configuration du script de conversation. Utilisez la commande start-chat à l'invite exec pour lancer le script de conversation manuellement.

  4. Voir « Délai d'attente : CONNECT » peut décrire plusieurs possibilités différentes :

    • Possibilité 1 : Le modem local ne passe pas l'appel. Vérifiez que le modem peut passer un appel en effectuant une connexion Telnet inverse au modem et en lançant manuellement une numérotation. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est passé par le modem en appelant manuellement un numéro local à l'aide de la commande ATDT<number> et en écoutant la sonnerie. Si aucun appel ne sort, activez les débogages RNIS. En cas de première suspicion de défaillance RNIS sur un BRI, vérifiez toujours le résultat de show isdn status. Les éléments clés à noter sont que la couche 1 doit être active et la couche 2 doit être dans un état MULTIPLE_FRAME_ESTABLISHED. Reportez-vous au chapitre 16 du Guide de dépannage des interréseaux, "Interprétation de l'état RNIS" pour obtenir des informations sur la lecture de ce résultat et les mesures correctives.

      Pour les appels RNIS sortants, debug isdn q931 et debug isdn events sont les meilleurs outils à utiliser. Heureusement, le débogage des appels sortants est très similaire au débogage des appels entrants. Un appel normalement réussi peut ressembler à ceci : 

      *Mar 20 21:07:45.025: ISDN BR0: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

      Notez que le message CONNECT est le principal indicateur de succès. Si aucun CONNECT n'est reçu, vous pouvez voir un message DISCONNECT ou RELEASE_COMP (version complète) suivi d'un code de cause : 

      *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

      La valeur de la cause indique deux choses.

      • Le deuxième octet de la valeur de 4 ou 6 octets indique le point du chemin d'appel de bout en bout à partir duquel DISCONNECT ou RELEASE_COMP a été reçu. Cela peut vous aider à localiser le problème.

      • Les troisième et quatrième octets indiquent la raison réelle de l'échec. Voir le tableau 9 pour la signification des différentes valeurs.

    • Possibilité 2 : Le modem distant ne répond pas. Testez-le en composant le modem distant avec un téléphone ordinaire. Essayez ceci:

      1. Vérifiez que le numéro de téléphone appelé est correct. Utilisez un combiné pour appeler le numéro de réception.

      2. Assurez-vous qu'un appel manuel est en mesure d'atteindre le modem asynchrone de réponse. Si un appel manuel peut atteindre le modem asynchrone de réponse, il se peut que la ligne BRI ne soit pas provisionnée pour autoriser les appels vocaux sortants.

      3. Si un appel manuel ne parvient pas à atteindre le modem asynchrone de réponse, modifiez les câbles téléphoniques sur le modem récepteur et essayez un téléphone normal sur la ligne du modem récepteur. Si l'appel peut être reçu par le téléphone normal, il y a probablement un problème avec le modem récepteur.

      4. Si l'appel manuel n'est toujours pas en mesure d'atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (connue) dans l'installation de réception. Si cela se connecte, demandez à l'opérateur de téléphonie de vérifier la ligne téléphonique vers le modem récepteur.

      5. S'il s'agit d'un appel longue distance, demandez à la partie d'origine d'essayer un autre numéro longue distance (connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut pas être provisionnée pour recevoir des appels longue distance. Si la ligne d'origine (BRI) ne peut pas atteindre d'autres numéros longue distance, elle n'est peut-être pas activée. Essayez les codes 10-10 pour les différentes compagnies interurbains.

      6. Enfin, essayez un autre numéro local (connu) de la ligne BRI d'origine. Si la connexion échoue toujours, demandez à l’opérateur téléphonique de vérifier l’accès de base (BRI).

    • Possibilité 3 : Le numéro composé est incorrect. Vérifiez le numéro en le composant manuellement. Corrigez la configuration, si nécessaire.

    • Possibilité 4 : La formation du modem prend trop de temps ou la valeur TIMEOUT est trop faible. Essayez d'augmenter la valeur TIMEOUT dans la commande chat-script. Si le délai d’attente est déjà de 60 secondes ou plus, il peut y avoir un problème de câble entre le modem et l’ETTD auquel il est connecté. Les échecs de formation peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour accéder au bas d'un problème de modem individuel, accédez à l'invite AT à l'invite du modem d'origine avec telnet inverse. Si possible, utilisez la connexion Telnet inverse pour accéder également à l'invite AT du modem récepteur. Utilisez ATM1 pour que le modem envoie des sons à son haut-parleur afin que les utilisateurs de chaque extrémité puissent entendre ce qui se passe sur la ligne.

      La musique a-t-elle du bruit ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'entraînent pas, appelez le numéro et écoutez le message statique. Il peut y avoir d'autres facteurs qui interférent avec la montée des trains. Inverse telnet au modem asynchrone et débogage.

  5. Si tout fonctionne correctement et que vous ne pouvez toujours pas vous connecter à votre DDR de modem asynchrone BRI, essayez le débogage PPP. Si le script de discussion se termine correctement et que les débogages PPP indiquent une défaillance, consultez la section "Dépannage PPP" du Chapitre 17 du Guide de dépannage de l'interréseau.

DDR RNIS PRI

  1. En cas de première suspicion de défaillance RNIS sur un PRI, vérifiez toujours le résultat de show isdn status. Les éléments clés à noter sont que la couche 1 doit être active et que la couche 2 doit être dans un état de MULTIPLE_FRAME_ESTABLISHED. Reportez-vous au chapitre 16 du Guide de dépannage des interréseaux, "Interprétation de l'état RNIS" pour obtenir des informations sur la lecture de ce résultat et les mesures correctives.

    Pour les appels RNIS sortants, debug isdn q931 et debug isdn events sont les meilleurs outils à utiliser. Heureusement, le débogage des appels sortants est très similaire au débogage des appels entrants. Un appel normalement réussi peut ressembler à ceci : 

    *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

    Notez que le message CONNECT est le principal indicateur de succès. Si aucun CONNECT n'est reçu, vous pouvez voir un message DISCONNECT ou RELEASE_COMP (version complète) suivi d'un code de cause : 

    *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    La valeur de la cause indique deux choses.

    • Le deuxième octet de la valeur de 4 ou 6 octets indique le point du chemin d'appel de bout en bout à partir duquel DISCONNECT ou RELEASE_COMP a été reçu. Cela peut vous aider à localiser le problème.

    • Les troisième et quatrième octets indiquent la raison réelle de l'échec. Voir le tableau 9 pour la signification des différentes valeurs.

    Remarque : L'impression suivante indique une défaillance de protocole supérieur :

    Cause i = 0x8090 - Normal call clearing

    L’échec de l’authentification PPP est une raison typique. Activez debug ppp negotiation et debug ppp authentication avant de supposer que l'échec de connexion est nécessairement un problème RNIS.

  2. Si le message RNIS CONNECT s'affiche et que les débogages PPP indiquent une défaillance, consultez la section "Dépannage PPP" du chapitre 17 du Guide de dépannage de l'interréseau.

DDR RNIS BRI

  1. Lorsque vous soupçonnez une défaillance RNIS sur un BRI, vérifiez toujours le résultat de la commande show isdn status. Les éléments clés à noter sont que la couche 1 doit être active et la couche 2 doit être dans un état de MULTIPLE_FRAME_ESTABLISHED. Reportez-vous au chapitre 16 du Guide de dépannage de l'interréseau, « Interpreting Show RNIS Status » (Interprétation de l'état RNIS) pour obtenir des informations sur la lecture de ce résultat et les mesures correctives à prendre.

    Pour les appels RNIS sortants, debug isdn q931 et debug isdn events sont les meilleurs outils à utiliser. Heureusement, le débogage des appels sortants est très similaire au débogage des appels entrants. Un appel normalement réussi peut ressembler à ceci : 

    *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

    Notez que le message CONNECT est le principal indicateur de succès. Si aucun CONNECT n'est reçu, vous pouvez voir un message DISCONNECT ou RELEASE_COMP (version complète) suivi d'un code de cause : 

    *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    La valeur de la cause indique deux choses.

    • Le deuxième octet de la valeur de 4 ou 6 octets indique le point du chemin d'appel de bout en bout à partir duquel DISCONNECT ou RELEASE_COMP a été reçu. Cela peut vous aider à localiser le problème.

    • Les troisième et quatrième octets indiquent la raison réelle de l'échec. Voir le tableau 9 pour la signification des différentes valeurs.

      Remarque : L'impression suivante indique une défaillance de protocole supérieur : 

      Cause i = 0x8090 - Normal call clearing

      L’échec de l’authentification PPP est une raison typique. Activez debug ppp negotiation et debug ppp authentication avant de supposer que l'échec de connexion est nécessairement un problème RNIS.

  2. Si le message RNIS CONNECT s'affiche et que les débogages PPP indiquent une défaillance, consultez la section "Dépannage PPP" du chapitre 17 du Guide de dépannage de l'interréseau.

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
09-Jul-2007
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits