Composition et accès : Routage à établissement de connexion à la demande (DDR)

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

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


Contenu


Introduction

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

Conditions préalables

Conditions requises

Ce document couvre trois scénarios principaux ; avant que vous commenciez à dépanner, déterminez quel type d'appel est tenté et allez à cette section :

Composants utilisés

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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). 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 numérotation est simplement l'application du réseau téléphonique public commuté (PSTN) qui porte des données au nom de l'utilisateur final. Il implique un périphérique de la CPE (CPE) envoyant au commutateur téléphonique par numéro de téléphone auquel pour diriger une connexion. Les AS3600, les AS5200, les AS5300, et les AS5800 sont tous les exemples des Routeurs qui ont la capacité d'exécuter un accès primaire (PRI) avec des banques des Modems numériques. L'AS2511, d'autre part, est un exemple d'un routeur qui communique avec des Modems externes.

Le marché des opérateurs s'est développé sensiblement, et le marché exige maintenant des densités plus élevées de modem. La réponse à ce besoin est un degré d'interopération plus élevé avec le matériel d'opérateur téléphonique et le développement du modem numérique. C'est un modem qui est capable de l'accès numérique direct au PSTN. En conséquence, on a maintenant développé des Modems plus rapides CPE qui tirent profit de la clarté du signal que les Modems numériques apprécient. Le fait que les Modems numériques se connectant dans le PSTN par un PRI ou l'accès de base (BRI) peuvent transmettre des données à 53k fini utilisant la norme de communication V.90, certifie au succès de l'idée.

Les premiers serveurs d'accès étaient les AS2509 et les AS2511. L'AS2509 pourrait prendre en charge 8 connexions entrantes utilisant des Modems externes, et l'AS2511 pourrait prendre en charge 16. L'AS5200 a été introduit avec 2 PRIs et pourrait prendre en charge 48 utilisateurs à l'aide des Modems numériques, et il a représenté un LEAP important en avant en technologie. Les densités de modem ont augmenté solidement avec l'AS5300 prenant en charge 4 et puis 8 PRIs. En conclusion, l'AS5800 a été introduit pour remplir besoins des installations de classe porteuse devant manipuler des douzaines d'entrant T1 et des centaines de connexions utilisateur.

Quelques Technologies périmées soutiennent mentionner dans une discussion sur le historique de la technologie de numéroteur. 56Kflex est (pre-V.90) une norme plus ancienne du modem 56K qui a été proposée par Rockwell. Cisco prend en charge la version 1.1 de la norme 56Kflex sur ses modems internes, mais recommande migrer les Modems CPE vers V.90 dès que possible. Une autre technologie périmée est l'AS5100. L'AS5100 était une co-entreprise entre Cisco et un fabricant de modem. L'AS5100 a été créé comme une manière d'augmenter la densité de modem par l'utilisation des cartes de modem de quad. Il a impliqué un groupe d'AS2511s établi comme cartes qui se sont insérées dans un fond de panier partagé par des cartes de modem de quad, et double carte de t1.

Conventions

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

Le Cisco IOS DDR initie l'appel

Tandis que l'approche de dépannage pour des débuts d'appels entrant au bas, dépannage qu'une connexion sortante commence au dessus.

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

  1. Le routage sur demande de cadran (DDR) initie-il un appel ? (La réponse A oui avance à la question suivante.)

  2. Si c'est un modem asynchrone, les scripts de conversation émettent-ils les commandes prévues ?

  3. L'appel le fait-il au PSTN ?

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

  5. L'appel se termine-il ?

  6. Le dépassement de données est-il au-dessus du lien ?

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

Pour voir si le numéroteur essaye de faire un appel à sa destination distante, utilisez le debug dialer events de commande. Plus d'informations détaillées peuvent être obtenues de mettent au point le paquet de numéroteur, mais la commande de paquet de numéroteur de débogage est ressource-intensive et ne devrait pas être utilisée sur un système sollicité qui a le fonctionnement d'interfaces de numéroteur multiple.

La ligne suivante de la sortie de debug dialer events pour un paquet IP répertorie le nom de l'interface DDR et la source et les adresses de destination du paquet :

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

Si le trafic n'initie pas une tentative de cadran, la raison la plus commune est configuration incorrecte (des définitions du trafic intéressant, de l'état de l'interface de numérotation, ou du routage).

Tableau 1 : Le trafic n'initie pas une tentative de cadran

Causes possibles Actions suggérées
Définitions manquantes ou incorrectes du « trafic intéressant »
  1. Utilisant la commande show running-config, assurez-vous que l'interface est configurée avec un dialer-group et qu'il y a un dialer-list de niveau global configuré avec un nombre équivalent.
  2. Assurez-vous que la commande de dialer-list est configurée pour permettre un protocole entier ou de permettre le trafic appariant une liste d'accès
  3. Vérifiez que la liste d'accès déclare des paquets allant à travers le lien être intéressante. Un test utile est d'utiliser le debug ip packet de commande de privileged exec [numéro de liste] utilisant le nombre de la liste d'accès pertinente. Puis tentative de cingler, ou d'envoyer autrement le trafic, à travers le lien. Si les filtres de trafic intéressant ont été correctement définis, vous verrez les paquets dans la sortie de débogage. S'il n'y a aucune sortie de débogage de ce test, la liste d'accès n'apparie pas les paquets.
État d'interface Utilisez le nom de <interface d'interfaces d'exposition de commande > pour s'assurer que l'interface est dans l'état « up/up (la mystification). »
  • Interface en mode « de réserve »
Une autre interface (primaire) sur le routeur a été configurée pour utiliser l'interface de numérotation comme Interface de sauvegarde. En outre, l'interface principale n'est pas dans un état de « vers le bas/en baisse », qui est exigé pour apporter l'interface de numérotation hors du mode standby. En outre, un retard de sauvegarde doit être configuré sur l'interface principale, ou la commande backup interface ne sera jamais imposée. Pour vérifier que l'interface de numérotation changera du « standby » en « up/up (mystification), » il est habituellement nécessaire de tirer le câble de l'interface principale. Simplement l'arrêt de l'interface principale avec l'arrêt de commande de configuration ne mettra pas l'interface principale dans « vers le bas/vers le bas, » mais à la place la mettra dans « administrativement en bas de » ? pas la même chose. En outre, si la connexion principale est par l'intermédiaire de Relais de trames, la configuration de Relais de trames doit être faite sur une sous-interface séquentielle point par point, et l'opérateur téléphonique doit passer le bit « actif ». Cette pratique est également connue en tant que « interface de gestion locale de bout en bout (le LMI). »
  • L'interface est « administrativement en bas de »
L'interface de numérotation a été configurée avec l'arrêt de commande. C'est également l'état par défaut de n'importe quelle interface quand un routeur de Cisco est amorcé pendant la toute première fois. Utilisez la commande de configuration d'interface aucun arrêt de retirer cette entrave.
Routage incorrect Émettez le show ip route de commande EXEC [a.b.c.d], où a.b.c.d est l'adresse de l'interface de numérotation du routeur distant. Si les unnumberedis d'IP utilisés sur le routeur distant, utilisent l'adresse de l'interface répertoriée dans l'unnumberedcommand d'IP. La sortie devrait afficher une artère à l'adresse distante par l'intermédiaire de l'interface de numérotation. S'il n'y a aucune artère, assurez-vous que la charge statique ou les Routes statiques flottantes ont été configurées en examinant la sortie du show running-config. S'il y a une artère par l'intermédiaire d'une interface autre que l'interface de numérotation, l'implication est que le DDR est utilisé comme sauvegarde. Examinez la configuration de routeur pour s'assurer que la charge statique ou les Routes statiques flottantes ont été configurées. La manière la plus sûre de tester le routage, dans ce cas, est de désactiver la connexion principale et exécuter le commandto du show ip route [a.b.c.d] vérifiez que l'artère appropriée a été installée dans la table de routage.

Remarque: Si vous tentez ceci pendant les fonctionnements en production du réseau, un événement de cadran peut être déclenché. Ce tri du test mieux est accompli pendant les cycles de maintenance planifiée.

Placement de l'appel

Si le routage et les filtres de trafic intéressant sont corrects, un appel devrait être initié. Ceci peut être vu à l'aide du debug dialer events :

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



Async1 DDR: Attempting to dial 5551212

Si la cause d'appel est vue mais aucune tentative n'est faite pour composer, la raison habituelle est un mappage de routeur d'appel mal configuré ou un profil du numéroteur.

Tableau 2 : Appel non placé

Problème éventuel Actions suggérées
Mappage de routeur d'appel mal configuré Employez la commande show running-config pour s'assurer que l'interface de numérotation est configurée avec au moins une instruction de mappage de numéroteur que des points à l'adresse de protocole et au numéro appelé du site distant.
Profil de routeur d'appel mal configuré Employez la commande show running-config pour s'assurer que l'interface de numérotation est configurée avec une commande du groupe de numérotation X et qu'une interface de numérotation sur le routeur est configurée avec un pool-member étant assorti de numéroteur X. Si des Profils de composeur ne sont pas correctement configurés, vous pouvez voir un message de débogage comme :
Dialer1: Can't place call, no dialer pool set
Assurez-vous qu'une chaîne de numéroteur est configurée.

Ensuite, identifiez le type de support qui est utilisé :

Modem asynchrone externe DDR

  1. Pour identifier un modem asynchrone externe DDR, utilisez les commandes, puis l'essai suivants de faire un appel :

    router# debug modem
    router# debug chat line <n>
    
    
  2. Pour des appels par modem, un script de conversation doit exécuter pour que l'appel poursuive. Pour le numéroteur DDR à base de cartes, le script de conversation est appelé par le paramètre de script du modem dans une commande de carte de numéroteur. Si le DDR est numéroteur basé sur profil, ceci est accompli par le script dialer de commande, configuré sur la ligne TTY. Les deux méthodes se fondent sur un script de conversation existant en configuration globale du routeur, par exemple :

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

    Dans l'un ou l'autre d'événement, la commande de visualiser l'activité de script de conversation est mettent au point la conversation. Si la chaîne de cadran (c'est-à-dire, numéro de téléphone) utilisée dans la carte de numéroteur ou la commande de chaîne de numéroteur étaient 5551212, la sortie de débogage ressemblerait à ce qui suit :

    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 prévu (c.-à-d. le bon nombre) basé sur le « envoi de la chaîne. » Si le script de conversation ne tente pas de faire l'appel prévu, vérifiez la configuration du script de conversation. Utilisez la commande de start-chat à la demande d'exécutif d'initier le script de conversation manuellement.

  4. Voir « prévoir de délai d'attente : CONNECTEZ » peut décrire plusieurs différentes possibilités :

    • Possibilité 1 : Le modem local ne place pas réellement l'appel. Vérifiez que le modem peut placer un appel en exécutant un telnet inverse au modem et en initiant manuellement un cadran. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est placé par le modem d'origine en demandant un numéro local manuellement avec le <number> de la commande ATDT et en écoutant la sonnerie.

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

      1. Assurez-vous que le numéro de téléphone appelé est correct. Utilisez un combiné téléphonique pour demander le numéro de réception. Soyez sûr d'utiliser le même câble au mur que le modem utilisait. 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 le remplacez comme nécessaire.

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

      3. Si l'appel manuel ne peut toujours pas atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (bon connu) dans l'installation de réception. Si cela se connecte CORRECT, ayez le contrôle de compagnie de téléphone la ligne téléphonique allant au modem de réception.

      4. Si c'est un appel longue distance, faites essayer au côté d'origine un autre numéro interurbain (bon connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut provisioned pour recevoir des appels longue distance. Si la ligne d'origine ne peut atteindre aucun autres numéros interurbains, elle peut ne pas faire activer la longue distance. Codes de l'essai 1010 pour différentes sociétés de fond.

      5. En conclusion, essayez un autre numéro local (bon connu) de la ligne d'origine. Si la connexion échoue toujours, ayez le contrôle de compagnie de téléphone la ligne d'origine.

    • Possibilité 3 : Le nombre étant composé est incorrect. Vérifiez le nombre en le composant manuellement. Corrigez la configuration, s'il y a lieu.

    • Possibilité 4 : L'apprentissage du modem prend trop long ou la valeur du dépassement de durée est si basse. Essayez augmenter la valeur du dépassement de durée dans la commande de chat-script. Si le DÉLAI D'ATTENTE est déjà de 60 secondes ou plus, il peut y a un problème de câble entre le modem et le DTE auxquels il est relié. Les échecs d'apprentissage peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour obtenir au bas d'un problème de modem individuel, attaquez-vous au à la demande au modem d'origine avec le telnet inverse. Si possible, atteignez au la demande du modem de réception aussi bien. La plupart des Modems indiqueront une sonnerie à la session de travail reliée à leur connexion DTE. Utilisation ATM1 de faire envoyer le modem des bruits à son haut-parleur de sorte que les gens à chaque extrémité puissent entendre ce qui se produit sur la ligne.

      La musique a-t-elle le bruit dans elle ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'exercent pas, demandez le numéro et écoutez la charge statique. Il peut y avoir d'autres facteurs gênant la série. Renversez le telnet au modem asynchrone et le mettez au point.

  5. Si tout fonctionne bien et vous ne pouvez pas encore se connecter sur votre modem asynchrone DDR de CAS, essayez l'élimination des imperfections de PPP. Utilisez les commandes :

    router# debug ppp negotiation
         router# debug ppp authentication
    

    Si le script de conversation se termine avec succès, les Modems sont connectés. Consultez la section « de PPP de dépannage » en chapitre 17 du guide de dépannage d'interréseau pour l'étape suivante en dépannant la connexion.

Modem asynchrone DDR de CAS T1/E1

  1. Pour identifier un modem asynchrone DDR de CAS T1/E1, utilisez les commandes, puis l'essai suivants de faire un appel :

    avertissement Avertissement :  S'exécuter met au point sur un système sollicité pourrait tomber en panne le routeur en surchargeant la CPU ou en débordant la mémoire tampon de console !

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

    Remarque: La commande de debug cas est disponible sur les Plateformes AS5200 et AS5300 de Cisco exécutant le Cisco IOS ? ? Version de logiciel 12.0(7)T et ultérieures. Dans des versions antérieures d'IOS, le service de commande interne devrait être écrit dans le niveau principal de la configuration du routeur et le debug-rbs csm de modem-gestion devrait être entré à la demande d'exécutif. L'élimination des imperfections sur Cisco AS5800 exige se connecter à la carte de joncteur réseau. (NO--debug-rbs csm de modem-gestion d'utilisation pour arrêter le débogage.)

  2. Pour des appels par modem, un script de conversation doit exécuter pour que l'appel poursuive. Pour le numéroteur DDR à base de cartes, le script de conversation est appelé par le paramètre de script du modem dans une commande de carte de numéroteur. Si le DDR est numéroteur basé sur profil, ceci est accompli par le script dialer de commande, configuré sur la ligne TTY. Les deux utilisations se fondent sur un script de conversation existant en configuration globale du routeur, comme :

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

    Dans l'un ou l'autre d'événement, la commande de visualiser l'activité de script de conversation est mettent au point la conversation. Si la chaîne de cadran (c'est-à-dire, numéro de téléphone) utilisée dans la carte de numéroteur ou la commande de chaîne de numéroteur étaient 5551212, la sortie de débogage ressemblerait à ce qui suit :

    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 prévu (c.-à-d. le bon nombre) basé sur le « envoi de la chaîne ». Si le script de conversation ne tente pas de faire l'appel prévu, vérifiez la configuration du script de conversation. Utilisez la commande de start-chat à la demande d'exécutif d'initier le script de conversation manuellement.

  4. Voir « prévoir de délai d'attente : CONNECTEZ » peut décrire plusieurs différentes possibilités :

    • Possibilité 1 : Le modem local ne place pas réellement l'appel. Vérifiez que le modem peut placer un appel en exécutant un telnet inverse au modem et en initiant manuellement un cadran. Si l'extrémité distante ne semble pas répondre, vérifiez l'appel est placé par le modem en demandant un numéro local manuellement avec le <number> de la commande ATDT et en écoutant la sonnerie.

      Pour appeler sortant par l'intermédiaire du t1 de CAS ou l'E1 et les modems numériques intégrés, une grande partie du dépannage est semblable à l'autre dépannage DDR. Le même juge vrai, aussi bien, pour des appels sortants de modem intégré au-dessus d'une ligne PRI. Les fonctionnalités uniques impliquées en faisant un appel exigent de cette manière l'élimination des imperfections spéciale en cas d'un échec d'appel.

      Quant à d'autres situations DDR, vous devez s'assurer qu'une tentative d'appel est exigée. Debug dialer events d'utilisation à cet effet. Référez-vous à IOS DDR, plus tôt en cet article.

      Avant qu'un appel puisse être placé, un modem doit être alloué pour l'appel. Pour visualiser ce processus et l'appel ultérieur, utilisez les commandes de débogage suivantes :

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

      Remarque: Le debug cas commande d'abord apparu dans la version IOS 12.0(7)T pour l'AS5200 et l'AS5300. Les versions antérieures de l'IOS utilisent un service au niveau système de commande de configuration interne avec le modem-gestion de commande EXEC mettent au point des rbs :

      Activer les debugs :

      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 
      

      Arrêter les debugs :

      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 exige se connecter à la carte de joncteur réseau. Ce qui suit est un exemple d'un appel sortant normal au-dessus d'un t1 de CAS qui provisioned et est configuré pour le FXS-Terre-commencement :

      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 debugs pour T1 et E1 avec d'autres types de signalisation sont semblables.

      Obtenir à ce point dans l'élimination des imperfections indique qu'appeler et les modems de réponse se sont exercés et se sont connectés et que les protocoles de couche plus élevée peuvent commencer à négocier. Si un modem est correctement alloué pour l'appel sortant mais la connexion n'obtient pas ceci loin, le t1 doit être examiné. Utilisez la commande du show controller t1/e1 de vérifier que T1/E1 fonctionne. Voir les lignes série de dépannage pour une explication de sortie de 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 ceci en composant le modem distant avec un téléphone ordinaire. Essayez ceci :

      1. Assurez-vous que le numéro de téléphone appelé est correct. Utilisez un combiné téléphonique pour demander le numéro de réception.

      2. Assurez-vous qu'un appel manuel peut atteindre le modem asynchrone de réponse. Si un appel manuel peut atteindre le modem asynchrone de réponse, la ligne de CAS ne peut provisioned pour permettre des communications voix sortantes.

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

      4. Si l'appel manuel ne peut toujours pas atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (bon connu) dans l'installation de réception. Si cela se connecte, ayez le contrôle de compagnie de téléphone la ligne téléphonique allant au modem de réception.

      5. Si c'est un appel longue distance, faites essayer au côté d'origine un autre numéro interurbain (bon connu). Si cela fonctionne l'installation ou la ligne de réception ne peut provisioned pour recevoir des appels longue distance. Si la ligne d'origine (de CAS) ne peut atteindre aucun autres numéros interurbains, elle peut ne pas faire activer la longue distance. Codes de l'essai 10-10 pour différentes sociétés de fond.

      6. En conclusion, essayez un autre numéro local (bon connu) de la ligne d'origine de CAS. Si la connexion échoue toujours, ayez le contrôle de compagnie de téléphone CAS.

    • Possibilité 3 : Le nombre étant composé est incorrect. Vérifiez le nombre en le composant manuellement. Corrigez la configuration, s'il y a lieu.

    • Possibilité 4 : L'apprentissage du modem prend trop long, ou la valeur du dépassement de durée est si basse. Essayez augmenter la valeur du dépassement de durée dans la commande de chat-script. Si le DÉLAI D'ATTENTE est déjà de 60 secondes ou plus, il peut y a un problème de câble entre le modem et le DTE auxquels il est relié. Les échecs d'apprentissage peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour obtenir au bas d'un problème de modem individuel, attaquez-vous au à la demande au modem d'origine avec le telnet inverse. Si possible, employez le telnet inverse pour atteindre au la demande du modem de réception aussi bien. Utilisation ATM1 de faire envoyer le modem des bruits à son haut-parleur de sorte que les gens à chaque extrémité puissent entendre ce qui se produit sur la ligne.

      La musique a-t-elle le bruit dans elle ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'exercent pas, demandez le numéro et écoutez la charge statique. Il peut y avoir d'autres facteurs gênant la série. Renversez le telnet au modem asynchrone et le mettez au point.

  5. Si tout fonctionne bien et vous ne pouvez pas encore se connecter sur votre modem asynchrone DDR de CAS, essayez l'élimination des imperfections de PPP. Si le script de conversation se termine avec succès et le PPP met au point indiquent une panne, consultez la section « de PPP de dépannage » en chapitre 17 du guide de dépannage d'interréseau.

Modem asynchrone DDR PRI

  1. Pour identifier un modem asynchrone DDR PRI, utilisez les commandes, puis l'essai suivants de faire un appel :

    avertissement Avertissement :  S'exécuter met au point sur un système sollicité pourrait tomber en panne le routeur en surchargeant la CPU ou en débordant la mémoire tampon de 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 des appels par modem, un script de conversation doit exécuter pour que l'appel poursuive. Pour le numéroteur DDR à base de cartes, le script de conversation est appelé par le paramètre de script du modem dans une commande de carte de numéroteur. Si le DDR est numéroteur basé sur profil, ceci est accompli par le script dialer de commande, configuré sur la ligne TTY. Les deux méthodes se fondent sur un script de conversation existant en configuration globale du routeur, comme :

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

    Dans l'un ou l'autre d'événement, la commande de visualiser l'activité de script de conversation est mettent au point la conversation. Si la chaîne de cadran (numéro de téléphone) utilisée dans la carte de numéroteur ou la commande de chaîne de numéroteur étaient 5551212, la sortie de débogage ressemblerait à ce qui suit :

    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 prévu (le bon nombre) basé sur le « envoi de la chaîne. » Si le script de conversation ne tente pas de faire l'appel prévu, vérifiez la configuration du script de conversation. Utilisez la commande de start-chat à la demande d'exécutif d'initier le script de conversation manuellement.

  4. Voir « prévoir de délai d'attente : CONNECTEZ » peut décrire plusieurs différentes possibilités :

    • Possibilité 1 : Le modem local ne place pas réellement l'appel. Vérifiez que le modem peut placer un appel en exécutant un telnet inverse au modem et en initiant manuellement un cadran. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est placé par le modem en demandant un numéro local manuellement avec le <number> de la commande ATDT et en écoutant la sonnerie. Si aucun appel ne sort, activez le RNIS met au point. Au premier soupçon d'une défaillance RNIS sur un BRI, vérifiez toujours la sortie de l'état de show isdn. Les choses principales à noter sont que la couche 1 devrait être en activité et la couche 2 devrait être dans un état de MULTIPLE_FRAME_ESTABLISHED. Voyez le chapitre 16 de guide de dépannage d'interréseau, « en interprétant l'état de show isdn » pour les informations sur lire cette sortie, aussi bien que pour des mesures correctives.

      Pour des appels RNIS sortants, le debug isdn q931 et les debug isdn event sont les meilleurs outils aux utiliser. Heureusement, les appels sortants de débogage est très semblable aux appels entrant de débogage. Un appel réussi normal pourrait 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 de CONNECTER est l'indicateur principal du succès. Si CONNECT n'est pas reçu, vous pouvez voir un DÉBRANCHEMENT ou un message RELEASE_COMP (release complète) suivi de 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 cause indique deux choses :

      • Le deuxième octet des 4 ou de la valeur 6-byte indique le point dans le chemin d'accès d'appel bout en bout duquel le DÉBRANCHEMENT ou le RELEASE_COMP a été reçu. Ceci peut vous aider à localiser le problème.

      • Les troisième et quatrièmes octets indiquent la raison réelle pour la panne. Voir le tableau 9 pour les significations des différentes valeurs.

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

      1. Assurez-vous que le numéro de téléphone appelé est correct. Utilisez un combiné téléphonique pour demander le numéro de réception.

      2. Assurez-vous qu'un appel manuel peut atteindre le modem asynchrone de réponse. Si un appel manuel peut atteindre le modem asynchrone de réponse, la ligne BRI ne peut provisioned pour permettre des communications voix sortantes.

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

      4. Si l'appel manuel ne peut toujours pas atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (bon connu) dans l'installation de réception. Si cela se connecte, ayez le contrôle de compagnie de téléphone la ligne téléphonique allant au modem de réception.

      5. Si c'est un appel longue distance, faites essayer au côté d'origine un autre numéro interurbain (bon connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut provisioned pour recevoir des appels longue distance. Si la ligne (BRI) d'origine ne peut atteindre aucun autres numéros interurbains, elle peut ne pas faire activer la longue distance. Codes de l'essai 1010 pour différentes sociétés de fond.

      6. En conclusion, essayez un autre numéro local (bon connu) de la ligne d'origine BRI. Si la connexion échoue toujours, ayez le contrôle de compagnie de téléphone le BRI.

    • Possibilité 3 : Le nombre étant composé est incorrect. Vérifiez le nombre en le composant manuellement. Corrigez la configuration, s'il y a lieu.

    • Possibilité 4 : L'apprentissage du modem prend trop long ou la valeur du dépassement de durée est si basse. Essayez augmenter la valeur du dépassement de durée dans la commande de chat-script. Si le DÉLAI D'ATTENTE est déjà de 60 secondes ou plus, il peut y a un problème de câble entre le modem et le DTE il est relié à. Les échecs d'apprentissage peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour obtenir au bas d'un problème de modem individuel, attaquez-vous au à la demande au modem d'origine avec le telnet inverse. Si possible, employez le telnet inverse pour atteindre au la demande du modem de réception aussi bien. Utilisation ATM1 de faire envoyer le modem des bruits à son haut-parleur de sorte que les gens à chaque extrémité puissent entendre ce qui se produit sur la ligne.

      La musique a-t-elle le bruit dans elle ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'exercent pas, demandez le numéro et écoutez la charge statique. Il peut y avoir d'autres facteurs gênant la série. Renversez le telnet au modem asynchrone et le mettez au point.

  5. Si tout fonctionne bien et vous ne pouvez pas encore se connecter sur votre modem asynchrone BRI DDR, essayez l'élimination des imperfections de PPP. Si le script de conversation se termine avec succès et le PPP met au point indiquent une panne, consultez la section « de PPP de dépannage » en chapitre 17 du guide de dépannage d'interréseau.

Modem asynchrone BRI DDR

Cette caractéristique travaille seulement à la plate-forme de Cisco 3640 utilisant Logiciel Cisco IOS version 12.0(3)T ou plus tard. Il exige une révision postérieure de matériel du module de réseau BRI. Ceci ne fonctionnera pas avec une carte d'interface WAN (WIC).

  1. Assurez-vous que code de pays est correct avec la commande de show modem. Utilisez les commandes, puis l'essai suivants de faire un appel :

    avertissement Avertissement :  S'exécuter met au point sur un système sollicité pourrait tomber en panne le routeur en surchargeant la CPU ou en débordant la mémoire tampon de 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 des appels par modem, un script de conversation doit exécuter pour que l'appel poursuive. Pour le numéroteur DDR à base de cartes, le script de conversation est appelé par le paramètre de script du modem dans une commande de carte de numéroteur. Si le DDR est numéroteur basé sur profil, ceci est accompli par le script dialer de commande, configuré sur la ligne TTY. Les deux utilisations se fondent sur un script de conversation existant en configuration globale du routeur, comme :

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

    Dans l'un ou l'autre d'événement, la commande de visualiser l'activité de script de conversation est mettent au point la conversation. Si la chaîne de cadran (numéro de téléphone) utilisée dans la carte de numéroteur ou la commande de chaîne de numéroteur étaient 5551212, la sortie de débogage ressemblerait à ce qui suit :

    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 prévu (le bon nombre) basé sur le « envoi de la chaîne. » Si le script de conversation ne tente pas de faire l'appel prévu, vérifiez la configuration du script de conversation. Utilisez la commande de start-chat à la demande d'exécutif d'initier le script de conversation manuellement.

  4. Voir « prévoir de délai d'attente : CONNECTEZ » peut décrire plusieurs différentes possibilités :

    • Possibilité 1 : Le modem local ne place pas réellement l'appel. Vérifiez que le modem peut placer un appel en exécutant un telnet inverse au modem et en initiant manuellement un cadran. Si l'extrémité distante ne semble pas répondre, vérifiez que l'appel est placé par le modem en demandant un numéro local manuellement avec le <number> de la commande ATDT et en écoutant la sonnerie. Si aucun appel ne sort, activez le RNIS met au point. Au premier soupçon d'une défaillance RNIS sur un BRI, vérifiez toujours la sortie de l'état de show isdn. Les choses principales à noter sont que la couche 1 devrait être en activité et la couche 2 devrait être dans un état de MULTIPLE_FRAME_ESTABLISHED. Voyez le chapitre 16 de guide de dépannage d'interréseau, « en interprétant l'état de show isdn » pour les informations sur lire ces sortie et mesures correctives.

      Pour des appels RNIS sortants, le debug isdn q931 et les debug isdn event sont les meilleurs outils aux utiliser. Heureusement, les appels sortants de débogage est très semblable aux appels entrant de débogage. Un appel réussi normal pourrait 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 de CONNECTER est l'indicateur principal du succès. Si CONNECT n'est pas reçu, vous pouvez voir un DÉBRANCHEMENT ou un message RELEASE_COMP (release complète) suivi de 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 cause indique deux choses.

      • Le deuxième octet des 4 ou de la valeur 6-byte indique le point dans le chemin d'accès d'appel bout en bout duquel le DÉBRANCHEMENT ou le RELEASE_COMP a été reçu. Ceci peut vous aider à localiser le problème.

      • Les troisième et quatrièmes octets indiquent la raison réelle pour la panne. Voir le tableau 9 pour les significations des différentes valeurs.

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

      1. Assurez-vous que le numéro de téléphone appelé est correct. Utilisez un combiné téléphonique pour demander le numéro de réception.

      2. Assurez-vous qu'un appel manuel peut atteindre le modem asynchrone de réponse. Si un appel manuel peut atteindre le modem asynchrone de réponse, la ligne BRI ne peut provisioned pour permettre des communications voix sortantes.

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

      4. Si l'appel manuel ne peut toujours pas atteindre le téléphone normal sur la ligne en question, essayez une autre ligne (bon connu) dans l'installation de réception. Si cela se connecte, ayez le contrôle de compagnie de téléphone la ligne téléphonique allant au modem de réception.

      5. Si c'est un appel longue distance, faites essayer au côté d'origine un autre numéro interurbain (bon connu). Si cela fonctionne, l'installation ou la ligne de réception ne peut provisioned pour recevoir des appels longue distance. Si la ligne (BRI) d'origine ne peut atteindre aucun autres numéros interurbains, elle peut ne pas faire activer la longue distance. Codes de l'essai 10-10 pour différentes sociétés de fond.

      6. En conclusion, essayez un autre numéro local (bon connu) de la ligne d'origine BRI. Si la connexion échoue toujours, ayez le contrôle de compagnie de téléphone le BRI.

    • Possibilité 3 : Le nombre étant composé est incorrect. Vérifiez le nombre en le composant manuellement. Corrigez la configuration, s'il y a lieu.

    • Possibilité 4 : L'apprentissage du modem prend trop long, ou la valeur du dépassement de durée est si basse. Essayez augmenter la valeur du dépassement de durée dans la commande de chat-script. Si le DÉLAI D'ATTENTE est déjà de 60 secondes ou plus, il peut y a un problème de câble entre le modem et le DTE il est relié à. Les échecs d'apprentissage peuvent également indiquer un problème de circuit ou une incompatibilité de modem.

      Pour obtenir au bas d'un problème de modem individuel, attaquez-vous au à la demande au modem d'origine avec le telnet inverse. Si possible, employez le telnet inverse pour atteindre au la demande du modem de réception aussi bien. Utilisation ATM1 de faire envoyer le modem des bruits à son haut-parleur de sorte que les gens à chaque extrémité puissent entendre ce qui se produit sur la ligne.

      La musique a-t-elle le bruit dans elle ? Si oui, nettoyez le circuit. Si les modems asynchrones ne s'exercent pas, demandez le numéro et écoutez la charge statique. Il peut y avoir d'autres facteurs gênant la série. Renversez le telnet au modem asynchrone et le mettez au point.

  5. Si tout fonctionne bien et vous ne pouvez pas encore se connecter sur votre modem asynchrone BRI DDR, essayez l'élimination des imperfections de PPP. Si le script de conversation se termine avec succès et le PPP met au point indiquent une panne, consultez la section « de PPP de dépannage » en chapitre 17 du guide de dépannage d'interréseau.

PRI LE RNIS DDR

  1. Au premier soupçon d'une défaillance RNIS un PRI, vérifiez toujours la sortie de l'état de show isdn. Les choses principales à noter sont que la couche 1 devrait être en activité et la couche 2 devrait être dans un état de MULTIPLE_FRAME_ESTABLISHED. Voyez le chapitre 16 de guide de dépannage d'interréseau, « en interprétant l'état de show isdn » pour les informations sur lire ces sortie et mesures correctives.

    Pour des appels RNIS sortants, le debug isdn q931 et les debug isdn event sont les meilleurs outils aux utiliser. Heureusement, les appels sortants de débogage est très semblable aux appels entrant de débogage. Un appel réussi normal pourrait 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 de CONNECTER est l'indicateur principal du succès. Si CONNECT n'est pas reçu, vous pouvez voir un DÉBRANCHEMENT ou un message RELEASE_COMP (release complète) suivi de 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 cause indique deux choses.

    • Le deuxième octet des 4 ou de la valeur 6-byte indique le point dans le chemin d'accès d'appel bout en bout duquel le DÉBRANCHEMENT ou le RELEASE_COMP a été reçu. Ceci peut vous aider à localiser le problème.

    • Les troisième et quatrièmes octets indiquent la raison réelle pour la panne. Voir le tableau 9 pour les significations des différentes valeurs.

    Remarque: L'impression suivante indique une défaillance de protocole plus élevé :

    Cause i = 0x8090 - Normal call clearing

    La défaillance d'authentification PPP est une raison typique. Activez le debug ppp negotiation et le debug ppp authentication avant de supposer que la panne de connexion est nécessairement un problème RNIS.

  2. Si le RNIS CONNECTENT le message est vu et le PPP met au point indiquent une panne, consultent la section « de PPP de dépannage » en chapitre 17 du guide de dépannage d'interréseau.

BRI LE RNIS DDR

  1. Au premier soupçon d'une défaillance RNIS sur un BRI, vérifiez toujours la sortie de l'état de show isdn. Les choses principales à noter sont que la couche 1 devrait être en activité et la couche 2 devrait être dans un état de MULTIPLE_FRAME_ESTABLISHED. Voyez le chapitre 16 de guide de dépannage d'interréseau, « en interprétant l'état de show isdn » pour les informations sur lire ces sortie et mesures correctives.

    Pour des appels RNIS sortants, le debug isdn q931 et les debug isdn event sont les meilleurs outils aux utiliser. Heureusement, les appels sortants de débogage est très semblable aux appels entrant de débogage. Un appel réussi normal pourrait 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 de CONNECTER est l'indicateur principal du succès. Si CONNECT n'est pas reçu, vous pouvez voir un DÉBRANCHEMENT ou un message RELEASE_COMP (release complète) suivi de 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 cause indique deux choses.

    • Le deuxième octet des 4 ou de la valeur 6-byte indique le point dans le chemin d'accès d'appel bout en bout duquel le DÉBRANCHEMENT ou le RELEASE_COMP a été reçu. Ceci peut vous aider à localiser le problème.

    • Les troisième et quatrièmes octets indiquent la raison réelle pour la panne. Voir le tableau 9 pour les significations des différentes valeurs.

      Remarque: L'impression suivante indique une défaillance de protocole plus élevé :

      Cause i = 0x8090 - Normal call clearing

      La défaillance d'authentification PPP est une raison typique. Activez le debug ppp negotiation et le debug ppp authentication avant de supposer que la panne de connexion est nécessairement un problème RNIS.

  2. Si le RNIS CONNECTENT le message est vu et le PPP met au point indiquent une panne, consultent la section « de PPP de dépannage » en chapitre 17 du guide de dépannage d'interréseau.


Informations connexes


Document ID: 14954