Composition et accès : "Réseaux numériques à intégration de services (RNIS), canal de signalisation associé (CAS)"

Technologie d'accès commuté : Techniques de dépannage

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Ces informations du guide de dépannage d'interréseau ont été signalées la première fois sur CCO. Comme service à nos clients, des chapitres sélectionnés ont été mis à jour avec la plupart d'informations à jour et précises. La mise à jour complète au guide de dépannage d'interréseau sera bientôt disponible dans la copie et en ligne.


Contenu


Introduction

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 Cisco3600, les AS5200, les AS5300, et les AS5800 sont tous les exemples des Routeurs qui ont la capacité d'exécuter un 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.

Conditions préalables

Conditions requises

Les lecteurs de ce document doivent avoir une bonne connaissance de ce qui suit :

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 un 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 Cisco2509 et les Cisco2511. 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.

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.

Conventions

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

Dépannage des appels entrant

Le dépannage des débuts d'un appel entrant au bas et fonctionne sa manière. Le flux général du raisonnement recherche ce qui suit :

  1. Voyons-nous l'appel arriver ? (La réponse A oui avance à la question suivante)

  2. L'extrémité réceptrice répond-elle à l'appel ?

  3. L'appel se termine-il ?

  4. Le dépassement de données est-il à travers le lien ?

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

Pour des connexions modem, des données appellent des aspects les mêmes qu'une session de travail étant livré dedans jusqu'à l'extrémité où l'appel de données va négocier le PPP.

Pour des appels entrant impliquant les Modems numériques, assurez-vous d'abord que le RNIS sous-jacent ou CAS reçoit l'appel. Si à l'aide d'un Modem externe, le RNIS et les sections sur le groupe CAS peuvent être ignorés.

Dépannage d'appel RNIS entrant

Utilisez le debug isdn q931 de commande. Voici un exemple de sortie d'une connexion réussie :

Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

Le message de configuration indique qu'une connexion est initiée par l'extrémité distante. Les numéros de référence d'appel sont mis à jour comme paire. Dans ce cas le numéro de référence d'appel pour le côté entrant de la connexion est 0x06, et le numéro de référence d'appel du côté sortant de la connexion est 0x86. La capacité de support (souvent désignée sous le nom du bearercap) indique au routeur dans ce qu'un peu l'appel est livré. Dans ce cas la connexion est le type 0x8890. Cette valeur indique la « vitesse 64 Kb/s RNIS ». Si le bearercap avait été 0x8090A2, il aurait indiqué le « u-law de la parole/communication voix ».

Si aucun message de configuration n'entrait, vous devriez vérifier le nombre correct en l'appelant manuellement, si c'est Voix provisioned. Vous devriez également vérifier le statut de l'interface RNIS (référez-vous utilisant la commande d'état de show isdn pour le dépannage BRI). Si ce tous les contrôles, s'assurent que l'émetteur d'appel fait l'appel correct. Ceci peut être fait en contactant l'opérateur téléphonique. L'émetteur d'appel peut tracer l'appel pour voir où il ? s étant envoyé. Si la connexion est de fond, essayez un opérateur interurbain différent utilisant code de l'interurbain 1010.

Si l'appel étant livré dedans est un appel par modem asynchrone, assurez-vous que la ligne provisioned pour permettre des communications voix.

Remarque: L'appel par modem asynchrone BRI est une caractéristique de 3600 Routeurs exécutant 12.0(3)T, ou plus tard. Il exige une révision matérielle récente du module de réseau de l'interface BRI. Les modules WIC ne prennent en charge pas modem asynchrone appelle.

Si l'appel arrivait mais ne se terminait pas, recherchez code de cause (voir le tableau 17-10). Une réussite est indiquée par le connecter-ACK.

Si c'est un appel par modem asynchrone, avancez à la section « de dépannage d'appel de modem entrant ».

En ce moment l'appel RNIS est connecté, mais aucune donnée n'a été vue trouver le lien par hasard. Utilisez le debug ppp de commande négocient pour voir si n'importe quel trafic PPP trouve la ligne par hasard. Si vous ne voyez pas le trafic, il peut y a une non-concordance de vitesse. Pour déterminer si c'est le cas, utilisez la commande de privileged exec de show running-config de visualiser la configuration de routeur. Vérifiez les entrées de commande de configuration d'interface de carte de numéroteur dans le routeur local et distant. Ces entrées devraient sembler semblables à ce qui suit :

dialer map ip 131.108.2.5 speed 56 name C4000

Pour des Profils de composeur, un map-class doit être défini afin de placer la vitesse. Notez que, par défaut, la tentative d'interfaces RNIS d'utiliser les transmissions 64K expédie sur chaque canal.

Pour des informations détaillées sur configurer des Cartes de composeur et des profils, référez-vous aux solutions de numérotation de Cisco IOS guide de configuration, à la référence de commandes de solutions de cadran, et au guide de configuration rapide de solutions de cadran.

Si vous recevez les paquets PPP valides, le lien est en hausse et fonctionner. Vous devriez poursuivre à la section « de PPP de dépannage » à ce moment.

Dépannage entrant d'appel de CAS

Pour dépanner la Connectivité de service de groupe CAS aux Modems, utilisez le debug modem de commandes, le debug modem csm, et le debug cas.

Remarque: Le debug cas commande d'abord apparu dans 12.0(7)T pour l'AS5200 et l'AS5300. Les versions antérieures de l'IOS utilisent le service au niveau système de commande de configuration interne avec le modem-gestion de commande EXEC mettent au point des rbs. Le débogage de ces informations sur un AS5800 exige se connecter à la carte de joncteur réseau elle-même.

D'abord, déterminez si le commutateur d'opérateur téléphonique allait le « offhook » pour signaler l'appel entrant. S'il ne faisait pas, vérifier le nombre s'appelant. Faites ceci en reliant un téléphone à la ligne téléphonique du côté d'origine et en demandant le numéro. Si l'appel entre correctement, le problème est dans le CPE d'origine. Si l'appel toujours n'apparaît pas sur CAS, vérifiez le t1 (le chapitre 15).In cet exemple, utilisent la commande d'interfaces série de débogage.

Les expositions suivantes une bonne connexion utilisant le debug modem csm :

Router# debug modem csm
CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.
MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0
CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
CSM_RING_INDICATION_PROC: RI is on
CSM_RING_INDICATION_PROC: RI is off
CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0
CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0

Dans cet exemple, l'appel a été dirigé vers un modem. Si votre appel était dirigé vers un modem, poursuivez à la section « de dépannage d'appel de modem entrant », ci-dessous.

Dépannage d'appel de modem entrant

Utilisez les appels de modem entrant suivants de pour le dépannage de commandes de débogage :

  • debug modem

  • debug modem csm (pour des modems numériques intégrés)

Utilisez les commandes de débogage suivantes dans la conjonction d'indiquer le nouvel appel étant livré dans :

  • debug isdn q931

  • debug cas

Assumer l'appel atteint le modem, le modem doit sélectionner l'appeler.

Conseils pour des Modems externes de débogage

Pour faciliter mettre au point sur un Modem externe s'est connectée à une ligne TTY, augmentent le volume de haut-parleur. Ceci aide à rendre quelques problèmes plus évidents.

Quand le modem d'origine appelle, le modem la réception sonne-t-elle ? Sinon, vérifiez le nombre et essayez un appel manuel du site distant. Essai utilisant un téléphone normal sur l'extrémité réceptrice aussi bien. Remplacez les câbles et le matériel comme nécessaire.

Prise d'appel par modem asynchrone

Si un Modem externe ne répond pas, vérifiez le câblage entre le modem et le serveur d'accès ou le routeur. Confirmez que le modem est connecté au téléscripteur ou au port auxiliaire sur le routeur à un câble roulé de RJ-45 et à un adaptateur MMOD DB-25. Cisco recommande et prend en charge cette configuration de câblage pour des ports de RJ-45. Notez que ces connecteurs sont typiquement étiquetés : Modem.

Le câblage de RJ-45 est livré dans quelques uns tape : directement, roulé, et croisé. Vous pouvez déterminer le type de câblage en tenant les deux extrémités d'un câble de RJ-45 côte à côte. Vous verrez huit bandes colorées, ou broches, à chaque extrémité.

  • Si l´ordre des broches colorées est identique à chaque bout, le câble est direct.

  • Si l´ordre des couleurs est inversé à chaque bout, le câble est roulé.

  • Le câble est un câble croisé si les couleurs indiquent ce qui suit :

RJ45 au câble croisé de RJ45 :

RJ45                  RJ45 
         5 ------------------ 2
         2 ------------------ 5
         4 ------------------ 1 
         1 ------------------ 4

Pour s'assurer la signalisation est OK, utilisent la commande de show line tracée les grandes lignes en chapitre 16.

Des problèmes de câblage de côté, un Modem externe doit être initialisés à la réponse automatique. Vérifiez le modem distant pour voir s'il est placé à la réponse automatique. Habituellement, un voyant lumineux AA est sur quand la réponse automatique est placée. Placez le modem distant à la réponse automatique si elle n'est pas déjà placée. Pour les informations sur vérifier et changer les configurations du modem, référez-vous à votre documentation de modem. Employez un telnet inverse pour initialiser le modem (référez-vous au chapitre 16).

Prise d'appel par modem de Digital (intégrée)

Sur un Modem externe il est clair si l'appel soit répondu, mais les modems internes exigent un appel manuel au nombre de réception. Écoutez la réponse de retour modifient la tonalité (ABT). Si vous n'entendez pas un ABT, vérifiez la configuration pour les deux choses suivantes :

  1. Assurez-vous que le modem d'isdn incoming-voice de commande existe sous toutes les interfaces RNIS manipulant des connexions de modem entrant.

  2. Sous la ligne configuration pour le téléscripteur du modem, assurez-vous que le modem inout de commande existe.

Il est également possible que le module de commutation d'appel (CSM) n'ait pas alloué un modem interne pour traiter l'appel entrant. Ce problème peut sont provoqué par par des groupes de modem ou de ressource étant configurés pour trop peu de connexions entrantes. Il peut également signifier que le serveur d'accès peut simplement être hors des Modems. Vérifiez la Disponibilité des Modems et ajustez le pool de modems ou les paramètres du gestionnaire de pool de ressources convenablement. Si un modem était alloué et la configuration affiche le modem inout, le rassemblement met au point et contact Cisco pour l'assistance.

Apprentissage du modem

Si le modem de réception soulève DSR, le trainup était réussi. Les échecs d'apprentissage peuvent 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 tandis qu'il a relié dans les POTS la ligne d'intérêt. Si appeler dans un modem in numérique un serveur d'accès Cisco, soit préparé pour enregistrer un fichier .wav de la musique d'apprentissage, ou de la séquence d'étude de la dégradation numérique (DILUÉE). Le DILUÉ est l'illustration musicale (ordre PCM) que le modem analogique V.90 d'origine indique le modem numérique de réception lire de retour. L'ordre permet au modem analogique pour discerner n'importe quelle dégradation numérique dans le circuit ; comme de plusieurs conversions D/A, un law/u-law, les bits revêtus d'une robe, ou les remplissages numériques. Si vous n'entendez pas le DILUÉ, les Modems n'ont pas négocié V.90 dans V.8/V.8bis (qu'est à dire., un problème de compatibilité de modem). Si vous entendez le DILUÉ et un recyclage dans V.34, le modem analogique a décidé que (sur la base de la lecture DILUÉE) ce V.90 était infaisable.

La musique a-t-elle le bruit dans elle ? Si oui, nettoyez alors le circuit.

Le client abandonne-il rapidement, sans exécuter la formation V.34 ? Par exemple, peut-être il ne sait pas quoi faire quand il entend V.8bis. Dans ce cas vous devriez essayer désactiver V.8bis (par conséquent K56Flex) sur le serveur (si acceptable). Vous devriez obtenir le nouveau microprogramme de client ou permuter le modem client. Alternativement, l'extrémité de composition a pu insérer cinq virgules à l'extrémité de la chaîne de cadran. Ceci retarde le modem appelant écoutent et entraîneront la tonalité V.8bis du serveur de réception au délai d'attente sans affecter le modem client. Cinq virgules dans la chaîne de cadran est une recommandation générale et pourrait avoir besoin s'ajuster pour tenir compte des conditions locales.

Établissement de session

En ce moment dans l'ordre, les Modems sont connectés et formés. Maintenant il est temps de découvrir si n'importe quel trafic trouve par hasard correctement.

Si la ligne recevant l'appel est configurée avec le ppp d'autoselect et l'interface asynchrone est configurée avec l'async mode interactive, utilisez le debug modem de commande pour vérifier le processus de sélection automatique. Car le trafic entre au-dessus de la liaison asynchrone, le serveur d'accès examinera le trafic pour déterminer si le trafic est basé sur caractère ou paquet paquet. Selon la détermination, le serveur d'accès alors commencera une session PPP ou ira pas plus loin qu'ayant une session d'EXEC sur la ligne.

Une séquence de sélection automatique normale avec les paquets LCP d'arrivée de PPP :

*Mar  1 21:34:56.958: TTY1: DSR came up
*Mar  1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar  1 21:34:56.970: TTY1: EXEC creation
*Mar  1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar  1 21:34:59.722: TTY1: Autoselect(2) sample 7E 

!--- The inbound traffic is displayed in hexadecimal format. This is based on the
!--- bits coming in over the line, regardless of whether the bits are ASCII
!--- characters or elements of a packet. The bits represented in this example are
!--- correct for a LCP packet. Anything different would be either a malformed packet
!--- or character traffic.

*Mar  1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar  1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate 

!--- Having determined that the inbound traffic is actually an LCP packet, the access
!--- server triggers the PPP negotiation process.

*Mar  1 21:34:59.746: TTY1: EXEC creation
*Mar  1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar  1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar  1 21:34:59.794: TTY1: destroy timer type 0
*Mar  1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up 

!--- The async interface changes state to up, and the PPP negotiation (not shown)
!--- commences.

Si l'appel est une session PPP et si l'async mode dedicated est configuré sur l'interface asynchrone, employez le debug ppp negotiation de commande pour voir si des paquets de demande de configuration proviennent l'extrémité distante. Met au point l'exposition ceux-ci comme CONFREQ. Si vous observez les paquets PPP d'arrivée et sortants, poursuivez « dépannage derrière le PPP ». Autrement, connectez de l'extrémité appelant session de caractère-mode (ou à une « exécutif ») (c'est-à-dire, une session de non-PPP).

Remarque: Si l'extrémité réceptrice affiche le modem asynchrone dédié sous l'interface asynchrone, un accès distant d'exécutif affiche seulement ce qui semble être des caractères incompréhensibles ASCII aléatoires. Pour permettre une session de travail et avoir toujours la capacité de PPP, utilisez l'async mode interactive de commande de configuration d'interface asynchrone. Sous la configuration de ligne associée, utilisez le ppp d'autoselect de commande.

Le modem ne peut pas envoyer ou recevoir des données

Si les Modems se connectent à une session de travail et donnée ne trouve pas par hasard, vérifiez les causes possibles suivantes et les lignes de conduite suggérées :

  • Le paramètre de vitesse de modem n'est pas verrouillé

    1. Utilisez la commande EXEC de show line sur le serveur d'accès ou le routeur. La sortie pour le port auxiliaire devrait indiquer les vitesses actuellement configurées de Tx et de Rx.

      Pour une explication de la sortie de la commande de show line, voyez la section « utilisant de debug commandes » en chapitre 15.

    2. Si la ligne n'est pas configurée à la vitesse correcte, utilisez la commande de configuration speed line de fixer la vitesse linéaire sur le serveur d'accès ou la ligne du routeur. Placez la valeur à la vitesse la plus élevée en commun entre le modem et le port de serveur d'accès ou de routeur. Pour placer le débit en bauds du terminal, utilisez la commande de configuration speed line. Cette commande place la transmission (au terminal) et reçoit (du terminal) des vitesses.

      Syntaxe :

      vitesse bps

      Description de syntaxe :

      bps - Débit dans des bits par seconde (bps). Le par défaut est de 9600 bps.

      L'exemple suivant place les lignes 1 et 2 sur un serveur d'accès Cisco 2509 à 115200 bps :

      line 1 2
      speed 115200

      Remarque: Si, pour quelque raison, vous ne pouvez pas utiliser le contrôle de flux, limitez la vitesse linéaire à 9600 bps. Des vitesses plus rapides sont susceptibles d'avoir comme conséquence les pertes de données.

    3. Utilisez la commande EXEC de show line de nouveau et la confirmez que la vitesse linéaire est fixée à la valeur désirée.

    4. Quand vous êtes certain que le serveur d'accès ou la ligne du routeur soit configuré pour la vitesse désirée, initiez une session de telnet inverse au modem par l'intermédiaire de cette ligne. Le pour en savoir plus, voient la section « établir une session Reverse Telnet à un modem » en chapitre 16.

    5. Utilisez une chaîne de commande du modem qui inclut la commande « de vitesse du verrouillage DTE » pour votre modem. Voir la votre documentation de modem pour la syntaxe de commande de configuration exacte.

    Remarque: La commande de vitesse du verrouillage DTE, qui pourrait également être mentionnée pendant que le débit de port s'ajustent ou mode tampon, est souvent liée à la manière dans laquelle le modem manipule la correction d'erreurs. Cette commande varie considérablement d'un modem à l'autre.

    Le verrouillage de la vitesse du modem s'assure que le modem communique toujours avec le serveur d'accès Cisco ou le routeur à la vitesse configurée sur le port auxiliaire Cisco. Si cette commande n'est pas utilisée, le modem retourne à la vitesse de la liaison de données (la ligne téléphonique), au lieu de la communication à la vitesse configurée sur le serveur d'accès.

  • Contrôle de flux matériel non configuré sur le modem ou routeur local ou distant

    1. Utilisez la commande EXEC d'aux.-ligne-nombre de show line et recherchez le suivant dans le domaine de capacités :

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      Le pour en savoir plus, se rapportent à interpréter le show line sorti en chapitre 16.

      S'il n'y a aucune mention de contrôle de flux matériel dans ce domaine, le contrôle de flux matériel n'est pas activé sur la ligne. Le contrôle de flux matériel pour des connexions de serveur-à-modem d'accès est recommandé.

      Pour une explication de la sortie de la commande de show line, voyez la section « utilisant des commandes de debug » en chapitre 15.

    2. Configurez le contrôle de flux matériel sur la ligne utilisant la ligne commande de flowcontrol hardware de configuration.

      Pour placer la méthode de contrôle du flux de données entre le terminal ou tout autre appareil de la série et le routeur, utilisez la ligne commande de flowcontrol de configuration. Utilisez le forme no de cette commande de désactiver le contrôle de flux.

      Syntaxe :

      flowcontrol {aucun | logiciel [verrouillage] [dans | ] | matériel [dans | ]}

      Description de syntaxe :

      • aucun - Arrête le contrôle de flux.

      • logiciel - Place le contrôle de flux logiciel. Un mot clé facultatif spécifie la direction : dans fait écouter le logiciel de Cisco IOS le contrôle de flux du périphérique connecté, et fait envoyer le logiciel les informations de contrôle de flux au périphérique connecté. Si vous ne spécifiez pas une direction, chacun des deux sont assumés.

      • verrouillage - Le rend impossible d'arrêter le contrôle de flux du serveur distant quand le périphérique connecté a besoin de contrôle de flux logiciel. Cette option s'applique aux connexions utilisant les protocoles de telnet ou de rlogin.

      • matériel - Place le contrôle de flux matériel. Un mot clé facultatif spécifie la direction : dans fait écouter le logiciel le contrôle de flux du périphérique connecté, et fait envoyer le logiciel les informations de contrôle de flux au périphérique connecté. Si vous ne spécifiez pas une direction, chacun des deux sont assumés. Pour plus d'informations sur le contrôle de flux matériel, voyez le manuel technique qui a été expédié avec votre routeur.

      Exemple :

      L'exemple suivant place le contrôle de flux matériel sur la ligne 7 :

      line 7
      flowcontrol hardware

      Remarque: Si pour quelque raison vous ne pouvez pas utiliser le contrôle de flux, limitez la vitesse linéaire à 9600 bps. Des vitesses plus rapides sont susceptibles d'avoir comme conséquence les pertes de données.

    3. Après l'activation du contrôle de flux matériel sur le serveur d'accès ou la ligne du routeur, initiez une session de telnet inverse au modem par l'intermédiaire de cette ligne. Le pour en savoir plus, voient la section « établir une session Reverse Telnet à un modem » en chapitre 16.

    4. Utilisez une chaîne de commande du modem qui inclut le RTS/CTS circulent la commande pour votre modem. Cette commande s'assure que le modem utilise la même méthode de contrôle de flux (c'est-à-dire, contrôle de flux matériel) que le serveur d'accès Cisco ou le routeur. Voir la votre documentation de modem pour la syntaxe de commande de configuration exacte.

  • Commandes de mappage de routeur d'appel mal configuré

    1. Utilisez la commande de privileged exec de show running-config de visualiser la configuration de routeur. Vérifiez les entrées de commande de carte de numéroteur pour voir si le mot clé broadcast est spécifié.

    2. Si le mot clé manque, ajoutez-le à la configuration.

      Syntaxe :

      dialer map protocol next-hop-address [adresse Internet de nom] [émission] [cadran-chaîne]

      Description de syntaxe :

      • protocole - Le protocole sujet au mappage. Les options incluent l'IP, l'IPX, la passerelle, et l'instantané.

      • adresse du prochain saut - L'adresse de protocole de l'interface asynchrone du site opposé.

      • adresse Internet de nom - Un paramètre requis utilisé dans l'authentification de PPP. C'est le nom du site distant pour lequel la carte de numéroteur est créée. Le nom distingue les majuscules et minuscules et doit apparier l'adresse Internet du routeur distant.

      • émission - Un mot clé facultatif qui annoncent des paquets (par exemple, des mises à jour de RIP IP ou IPX RIP/SAP) qui est expédié à la destination distante. Dans des configurations d'échantillon statiques de routage, des mises à jour de routage ne sont pas désirées et le mot clé broadcast est omis.

      • cadran-chaîne - Le numéro de téléphone du site distant. Tous les codes d'accès (par exemple, 9 à sortir d'un bureau, de codes téléphoniques internationaux, de codes postaux) doivent être inclus.

    3. Assurez-vous que les commandes de carte de numéroteur spécifient les adresses du prochain saut correctes.

    4. Si l'adresse du prochain saut est incorrecte, changez-la utilisant la commande de carte de numéroteur.

    5. Assurez-vous que toutes autres options dans des commandes de carte de numéroteur sont correctement spécifiées pour le protocole que vous utilisez.

    Pour des informations détaillées sur configurer des Cartes de composeur, référez-vous au guide de configuration de réseau d'étendu de Cisco IOS et à la référence de commandes de réseau d'étendu.

  • Problème avec le modem d'appel

    • Assurez-vous que le modem d'appel est opérationnel et est sécurisé connecté au port approprié. Déterminez si un autre modem fonctionne une fois connecté à la même chose mettent en communication.

Le débogage d'une session exec en entrée se range généralement dans quelques catégories principales :

Le client distant ne reçoit aucune demande d'exécutif

  • L'autoselect est activé sur la ligne

    La tentative d'accéder au mode d'exécution en appuyant sur entrent.

  • La ligne est configurée avec l'aucune commande EXEC

    1. Utilisez la commande EXEC de show line de visualiser le statut de la ligne correspondante.

      Vérifiez les capacités mettent en place pour voir s'il indique le « exécutif supprimé. » Si c'est le cas, l'aucune ligne commande d'exécutif de configuration n'est activée.

    2. Configurez la ligne d'exécutif commande de configuration sur la ligne de permettre des sessions d'EXEC à initier. Cette commande n'a aucun argument ou mot clé.

    L'exemple suivant active l'exécutif sur la ligne 7 :

    line 7 
    exec
  • Le contrôle de flux n'est pas activé.

    ou

    Le contrôle de flux est activé seulement sur un périphérique (DTE ou DCI).

    ou

    Le contrôle de flux misconfigured.

    1. Utilisez la commande EXEC d'aux.-ligne-nombre de show line et recherchez le suivant dans le domaine de capacités :

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
      

      Le pour en savoir plus, se rapportent à interpréter le show line sorti en chapitre 16.

      S'il n'y a aucune mention de contrôle de flux matériel dans ce domaine, le contrôle de flux matériel n'est pas activé sur la ligne. Le contrôle de flux matériel pour des connexions de serveur-à-modem d'accès est recommandé.

      Pour une explication de la sortie de la commande de show line, voyez la section « utilisant de debug commandes » en chapitre 15.

    2. Configurez le contrôle de flux matériel sur la ligne utilisant la ligne commande de flowcontrol hardware de configuration. L'exemple suivant place le contrôle de flux matériel sur la ligne 7 :

      line 7
      flowcontrol hardware

      Remarque: Si pour quelque raison vous ne pouvez pas utiliser le contrôle de flux, limitez la vitesse linéaire à 9600 bps. Des vitesses plus rapides sont susceptibles d'avoir comme conséquence les pertes de données.

    3. Après l'activation du contrôle de flux matériel sur le serveur d'accès ou la ligne du routeur, initiez une session de telnet inverse au modem par l'intermédiaire de cette ligne. Le pour en savoir plus, voient la section « établir une session Reverse Telnet à un modem » en chapitre 16.

    4. Utilisez une chaîne de commande du modem qui inclut le RTS/CTS circulent la commande pour votre modem. Cette commande s'assure que le modem utilise la même méthode de contrôle de flux (c'est-à-dire, contrôle de flux matériel) que le serveur d'accès Cisco ou le routeur. Voir la votre documentation de modem pour la syntaxe de commande de configuration exacte.

  • Le paramètre de vitesse de modem n'est pas verrouillé

    1. Utilisez la commande EXEC de show line sur le serveur d'accès ou le routeur. La sortie pour le port auxiliaire devrait indiquer les vitesses actuellement configurées de Tx et de Rx.

      Pour une explication de la sortie de la commande de show line, voyez la section « utilisant de debug commandes » en chapitre 15.

    2. Si la ligne n'est pas configurée à la vitesse correcte, utilisez la commande de configuration speed line de fixer la vitesse linéaire sur le serveur d'accès ou la ligne du routeur. Placez la valeur à la vitesse la plus élevée en commun entre le modem et le port de serveur d'accès ou de routeur. Pour placer le débit en bauds du terminal, utilisez la commande de configuration speed line. Cette commande place la transmission (au terminal) et reçoit (du terminal) des vitesses.

      Syntaxe :

      vitesse bps

      Description de syntaxe :

      bps - Débit dans des bits par seconde (bps). Le par défaut est de 9600 bps.

      Exemple :

      L'exemple suivant place les lignes 1 et 2 sur un serveur d'accès Cisco 2509 à 115200 bps :

      line 1 2
      speed 115200

      Remarque: Si pour quelque raison vous ne pouvez pas utiliser le contrôle de flux, limitez la vitesse linéaire à 9600 bps. Des vitesses plus rapides sont susceptibles d'avoir comme conséquence les pertes de données.

    3. Utilisez la commande EXEC de show line de nouveau et la confirmez que la vitesse linéaire est fixée à la valeur désirée.

    4. Quand vous êtes certain que le serveur d'accès ou la ligne du routeur soit configuré pour la vitesse désirée, initiez une session de telnet inverse au modem par l'intermédiaire de cette ligne. Le pour en savoir plus, voient la section « établir une session Reverse Telnet à un modem » en chapitre 16.

    5. Utilisez une chaîne de commande du modem qui inclut la commande de vitesse du verrouillage DTE pour votre modem. Voir la votre documentation de modem pour la syntaxe de commande de configuration exacte.

    Remarque: La commande de vitesse du verrouillage DTE, qui pourrait également être mentionnée pendant que le débit de port s'ajustent ou mode tampon, est souvent liée à la manière dans laquelle le modem manipule la correction d'erreurs. Cette commande varie considérablement d'un modem à l'autre.

    Le verrouillage de la vitesse du modem s'assure que le modem communique toujours avec le serveur d'accès Cisco ou le routeur à la vitesse configurée sur le port auxiliaire Cisco. Si cette commande n'est pas utilisée, le modem retourne à la vitesse de la liaison de données (la ligne téléphonique) au lieu de la communication à la vitesse configurée sur le serveur d'accès.

Les session d'accès à distance par réseau commuté voit des « déchets »

  • Le paramètre de vitesse de modem n'est pas verrouillé

    1. Utilisez la commande EXEC de show line sur le serveur d'accès ou le routeur. La sortie pour le port auxiliaire devrait indiquer les vitesses actuellement configurées de Tx et de Rx.

      Pour une explication de la sortie de la commande de show line, voyez la section « utilisant de debug commandes » en chapitre 15.

    2. Si la ligne n'est pas configurée à la vitesse correcte, utilisez la commande de configuration speed line de fixer la vitesse linéaire sur le serveur d'accès ou la ligne du routeur. Placez la valeur à la vitesse la plus élevée en commun entre le modem et le port de serveur d'accès ou de routeur.

      Pour placer le débit en bauds du terminal, utilisez la commande de configuration speed line. Cette commande place la transmission (au terminal) et reçoit (du terminal) des vitesses.

      Syntaxe :

      vitesse bps

      Description de syntaxe :

      bps de débit dans des bits par seconde (bps). Le par défaut est de 9600 bps.

      Exemple :

      L'exemple suivant place les lignes 1 et 2 sur un serveur d'accès Cisco 2509 à 115200 bps :

      ligne 1 2

      vitesse 115200

      Remarque: Si pour quelque raison vous ne pouvez pas utiliser le contrôle de flux, limitez la vitesse linéaire à 9600 bps. Des vitesses plus rapides sont susceptibles d'avoir comme conséquence les pertes de données.

    3. Utilisez la commande EXEC de show line de nouveau et la confirmez que la vitesse linéaire est fixée à la valeur désirée.

    4. Quand vous êtes certain que le serveur d'accès ou la ligne du routeur soit configuré pour la vitesse désirée, initiez une session de telnet inverse au modem par l'intermédiaire de cette ligne. Le pour en savoir plus, voient la section « établir une session Reverse Telnet à un modem » en chapitre 16.

    5. Utilisez une chaîne de commande du modem qui inclut la commande de vitesse du verrouillage DTE pour votre modem. Voir la votre documentation de modem pour la syntaxe de commande de configuration exacte.

    Remarque: La commande de vitesse du verrouillage DTE, qui pourrait également être mentionnée pendant que le débit de port s'ajustent ou mode tampon, est souvent liée à la manière dans laquelle le modem manipule la correction d'erreurs. Cette commande varie considérablement d'un modem à l'autre.

    Le verrouillage de la vitesse du modem s'assure que le modem communique toujours avec le serveur d'accès Cisco ou le routeur à la vitesse configurée sur le port auxiliaire Cisco. Si cette commande n'est pas utilisée, le modem retourne à la vitesse de la liaison de données (la ligne téléphonique) au lieu de la communication à la vitesse configurée sur le serveur d'accès.

Symptôme : La session distante de dialin s'ouvrent en session déjà existante initiée par un autre utilisateur. C'est-à-dire, au lieu d'obtenir une invite d'ouverture de connexion, un utilisateur de dialin voit une session établie par un autre utilisateur (qui pourrait être une invite de commande UNIX, une session d'éditeur de texte, et ainsi de suite).

Le session d'accès à distance par réseau commuté s'ouvre en session existante

  • Modem configuré pour DCD toujours élevé

    1. Le modem devrait être modifié pour avoir la haute DCD seulement sur le CD. Ce fait habituellement à l'aide de la chaîne de commande du modem &C1, mais vérifie votre documentation de modem pour la syntaxe exacte pour votre modem.

    2. Vous pourriez devoir configurer la ligne du serveur d'accès à laquelle le modem est connecté à l'aucune ligne commande d'exécutif de configuration. Effacez la ligne avec la commande de privileged exec de clear line, initiez une session de telnet inverse avec le modem, et modifiez le modem de sorte que DCD soit élevé seulement sur le CD.

    3. Finissez la session de telnet en écrivant le débranchement et modifiez la ligne du serveur d'accès avec la ligne commande d'exécutif de configuration

  • Le contrôle de modem n'est pas activé sur le serveur d'accès ou le routeur

    1. Utilisez la commande EXEC de show line sur le serveur d'accès ou le routeur. La sortie pour le port auxiliaire devrait être inout ou RIisCD d'exposition dans la colonne Modem. Ceci indique que le contrôle de modem est activé sur la ligne du serveur d'accès ou du routeur.

      Pour une explication de la sortie de show line, voyez la section « utilisant de debug commandes » en chapitre 15.

    2. Configurez la ligne pour le contrôle de modem utilisant la ligne commande de modem inout de configuration. Le contrôle de modem est maintenant activé sur le serveur d'accès.

    Remarque: Soyez sûr d'utiliser la commande de modem inout au lieu de la commande de modem dialin tandis que la Connectivité du modem est en question. La dernière commande permet à la ligne pour recevoir des appels entrant seulement. Des appels sortants seront refusés, le rendant impossible d'établir une session de telnet avec le modem pour le configurer. Si vous voulez activer la commande de modem dialin, faites ainsi seulement après que vous êtes certain que le modem fonctionne correctement.

  • Câblage incorrect

    1. Vérifiez le câblage entre le modem et le serveur d'accès ou le routeur. Confirmez que le modem est connecté au port auxiliaire sur le serveur d'accès ou le routeur à un câble roulé de RJ-45 et à un adaptateur MMOD DB-25. Cette configuration de câblage est recommandée et prise en charge par Cisco pour des ports de RJ-45. Ces connecteurs sont typiquement étiquetés : Modem.

      Il y a deux types de câblage de RJ-45 : directement et roulé. Si vous vous tenez les deux fins d'un RJ-45 câblent côte à côte, vous verrez huit bandes colorées, ou broches, à chaque extrémité. Si la commande des broches colorées est identique à chaque extrémité, alors le câble est droit. Si la commande des couleurs est renversée à chaque extrémité, alors le câble est roulé.

      Le câble enroulé (CAB-500RJ) est standard avec le 2500/CS500 de Cisco.

    2. Utilisez la commande EXEC de show line de vérifier que le câblage est correct. Voyez l'explication de la sortie de commande de show line dans la section « utilisant des commandes de debug » en ce chapitre 15.

Le modem de réception commuté ne déconnecte pas correctement

  • Le modem ne sent pas le DTR

    Entrez dans la chaîne de commande du modem du raccrocher DTR. Cette commande indique le modem relâcher le transporteur quand le signal DTR plus n'est reçu.

    Sur un modem compatible Hayes la chaîne &D3 est utilisée généralement pour configurer le raccrocher DTR sur le modem. Pour la syntaxe exacte de cette commande, voyez la documentation pour votre modem.

  • Le contrôle de modem n'est pas activé sur le routeur ou le serveur d'accès

    1. Utilisez la commande EXEC de show line sur le serveur d'accès ou le routeur. La sortie pour le port auxiliaire devrait afficher l'inout ou le RIisCD dans la colonne Modem. Ceci indique que le contrôle de modem est activé sur la ligne du serveur d'accès ou du routeur.

      Pour une explication de la sortie de show line, voyez la section « utilisant de debug commandes » en chapitre 15.

    2. Configurez la ligne pour le contrôle de modem utilisant la ligne commande de modem inout de configuration. Le contrôle de modem est maintenant activé sur le serveur d'accès.

    Remarque: Soyez sûr d'utiliser la commande de modem inout au lieu de la commande de modem dialin tandis que la Connectivité du modem est en question. La dernière commande permet à la ligne pour recevoir des appels entrant seulement. Des appels sortants seront refusés, le rendant impossible d'établir une session de telnet avec le modem pour le configurer. Si vous voulez activer la commande de modem dialin, faites ainsi seulement après que vous êtes certain que le modem fonctionne correctement.

Dépannage des appels sortants

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 recherche 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)

Vérifier l'utilisation du routeur d'appels

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).

Le trafic n'initie pas une tentative de cadran

  • 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, alors la liste d'accès n'apparie pas les paquets.

  • État d'interface

    Employez les interfaces d'exposition de commande [nom d'interface] pour s'assurer que l'interface est dans l'état « up/up (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 » - pas de 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 « LMI de bout en bout ».

    • 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ù adresse d'isthe a.b.c.d 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 d'exécuter la commande du show ip route [a.b.c.d] de vérifier 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.

Appel non placé

Quelques problèmes éventuels et actions suggérées sont répertoriés ci-dessous :

  • 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 qui 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.

Appeler sortant async - Vérifiez l'exécution de script de conversation

Si l'appel sortant est un appel 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, 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

Des problèmes de script de conversation peuvent être divisés en trois catégories :

  • Erreur de configuration

  • Panne de modem

  • Panne de connexion

Panne de script de conversation

Cette liste affiche que les sorties possibles de mettent au point des talks-show et des actions suggérées :

  • aucun script de conversation assorti trouvé pour [nombre]

    Un script de conversation n'a pas été configuré. Additionnez un.

  • Dialout de script de conversation terminé, état = connexion chronométrée ; serveur distant ne répondant pas

    Le modem ne répond pas au script de conversation. Vérifiez la transmission avec le modem (référez-vous au tableau 16-2 en chapitre 16).

  • Prévoir de délai d'attente : CONNECTEZ

    • 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.

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

    • 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. Si le modem local est externe, indiquez le volume de haut-parleur du modem et écoutez les tonalités de trainup. Si le trainup est abruptement découpé, 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, voyez la section d'apprentissage du modem.

Appeler sortant RNIS

Au premier soupçon d'une défaillance RNIS, un BRI ou 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 la « interprétation de la section sortie par état de show isdn » en chapitre 16 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 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

!--- The CONNECT message is the key indicator of success. If a CONNECT is not received,
!--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by
!--- a cause code (see below)

*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 d'où dans le chemin d'accès d'appel bout en bout 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. Voyez les tables qui suivent pour les significations des différentes valeurs.

Remarque: L'impression suivante indique habituellement 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

Champs Code de motif

Le tableau 17-9 répertorie les champs Code de motif RNIS qui affichent dans le format suivant dans les commandes de débogage :

i=0x y1 y2 z1 z2 [a1 a2]

Champs Code de motif RNIS

Champ Description de valeur
0x Les valeurs qui suivent sont dans l'hexadécimal.
y1 Codage 8--ITU-T standard.
y2 réseau A de l'utilisateur distant 7--International de service de réseau de l'utilisateur distant 5--Private de service de réseau du réseau 4--Public de l'utilisateur local 3--Transit de service de réseau de l'utilisateur local 2--Public de service de réseau 0--User 1--Private--Réseau au delà de point d'interconnexion de réseaux
z1 Classe (le nombre hexadécimal plus significatif) de valeur de cause. Référez-vous à la prochaine table pour des informations détaillées sur des valeurs possibles.
z2 Valeur (le nombre hexadécimal moins significatif) de valeur de cause. Référez-vous à la prochaine table pour des informations détaillées sur des valeurs possibles.
a1 Champ Diagnostic (facultatif) qui est toujours 8.
a2 Champ Diagnostic (facultatif) qui est l'une des valeurs suivantes : 0--Unknown 1--Permanent 2--Transient

Valeurs de cause RNIS

Le tableau suivant présente des descriptions de certaines des la plupart des valeurs de cause courante de l'élément d'information de cause - les troisième et quatrièmes octets de code de cause. Pour plus d'informations complètes sur des codes et des valeurs RNIS, référez-vous compréhension derrière codes de motif de déconnexion de debug isdn q931.

Valeur hexadécimale Cause Explication
81 Nombre (non affecté) non affecté L'isdn number a été envoyé au commutateur dans le format correct ; cependant, le nombre n'est assigné à aucun équipement de destination.
90 Effacement d'appel normal L'effacement d'appel normal s'est produit.
91 Utilisateur occupé Le système appelé reconnaît la demande de connexion mais ne peut pas recevoir l'appel parce que tous les canaux B sont en service.
92 Aucun répondre d'utilisateur La connexion ne peut pas être terminée parce que la destination ne répond pas à l'appel.
93 Pas de réponse d'utilisateur (utilisateur alerté) La destination réagit à la requête de connexion mais ne complète pas la connexion dans le temps prescrit. Le problème est à l'extrémité distante de la connexion.
95 Appel rejeté La destination est capable de recevoir l'appel mais rejeté lui pour une raison inconnue.
9C Format de numéro incorrect La connexion pourrait ne pas être établie parce que l'adresse de destination a été présentée dans un format non identifiable ou parce que l'adresse de destination était inachevée.
9F Normal, non spécifié Signale l'occurrence d'un événement normal quand aucune cause standard ne s'applique. Aucune action requise.
A2 Aucun circuit/canal disponible La connexion ne peut pas être établie parce qu'aucun canal approprié n'est disponible pour prendre l'appel.
A6 Réseau en panne La destination ne peut pas être atteinte parce que le réseau ne fonctionne pas correctement, et la condition pourrait durer pendant une longue période. Un immédiat rebranche la tentative sera probablement infructueux.
Courant alternatif Circuit/canal demandés non disponible Le matériel distant ne peut pas fournir le canal demandé pour une raison inconnue. Ceci pourrait être un problème provisoire.
B2 Installation demandée non abonnée Le matériel distant prend en charge le service supplémentaire demandé par abonnement seulement. C'est fréquemment une référence au service interurbain.
B9 Capacité de support non autorisée L'utilisateur a demandé une capacité de support que le réseau fournit, mais l'utilisateur n'est pas autorisé à l'utiliser. Ceci pourrait être un problème d'abonnement.
D8 Destination incompatible Indique qu'une tentative a été faite pour se connecter au matériel le non-RNIS. Par exemple, à une ligne analogique.
E0 L'élément d'information obligatoire manque Le matériel de réception a reçu un message qui n'a pas inclus un des éléments d'information obligatoire. C'est habituellement dû à un erreur de canal D. Si cette erreur se produit systématiquement, signalez-la à votre fournisseur de services RNIS.
E4 Contenus avec éléments d'informations incorrectes Le matériel distant a reçu un message qui inclut les informations non valides dans l'élément d'information. C'est habituellement dû à un erreur de canal D.

Appeler sortant de CAS

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 à vérifier l'utilisation du routeur d'appels.

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 :

  • debug modem

  • debug modem csm

  • 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# 
router#modem-mgmt csm no-debug-rbs 
neat msg at slot 0: debug-rbs is off 

Remarque: 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é. Référez-vous au chapitre 15 pour l'information de dépannage de t1.

Dépannage du PPP

Le dépannage de la partie de PPP d'une connexion commence quand vous savez que la connexion de cadran, le RNIS ou l'async, établit avec succès.

Il est important de comprendre ce que ressemble à un ordre réussi de debug ppp avant que vous dépanniez la négociation PPP. De cette façon, en comparant un PPP défectueux mettez au point la session contre un ordre réussi-terminé de debug ppp t'enregistre le temps et l'effort.

Être suit un exemple d'un ordre réussi de PPP. Voir les détails de négociation LCP de PPP pour une description détaillée des champs de sortie.

Montecito# 
Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up
Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25
Mar 13 10:57:15.415: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.415: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.415: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.415: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.415: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25
Mar 13 10:57:15.543: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.543: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.543: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.543: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.547: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23
Mar 13 10:57:16.919: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:16.919: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:16.919: As1 LCP:    PFC (0x0702)
Mar 13 10:57:16.919: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: State is Open
Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end
Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4
Mar 13 10:57:17.191: As1 PPP: Phase is UP
Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10
Mar 13 10:57:17.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15
Mar 13 10:57:17.319: As1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
Mar 13 10:57:17.319: As1 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
Mar 13 10:57:17.319: As1 LCP:  (0x80FD0101000F12060000000111050001)
Mar 13 10:57:17.319: As1 LCP:  (0x04)
Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10
Mar 13 10:57:17.319: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1,
 changed state to up
Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd
Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10
Mar 13 10:57:19.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10
Mar 13 10:57:19.315: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34
Mar 13 10:57:20.307: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22
Mar 13 10:57:20.543: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22
Mar 13 10:57:20.547: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: State is Open
Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1

Remarque: Votre met au point peut apparaître dans un format différent. Cet exemple affiche au format plus nouveau de sortie de débogage de PPP ce qui a été modifié dans la version IOS 11.2(8). Voir le chapitre 16 pour un exemple de l'élimination des imperfections de PPP avec les versions plus anciennes de l'IOS.

Détails de négociation LCP de PPP

Groupe date/heure Description
10:57:15.415 Demande de configuration sortante (O CONFREQ). Le NAS envoie un paquet de requêtes de configuration PPP en sortie au client.
10:57:15.543 Accusé de réception entrant de configuration (I CONFACK). Le client reconnaît la demande du PPP de Montecito.
10:57:16.919 Demande de configuration entrante (I CONFREQ). Le client veut négocier le protocole de rappel.
10:57:16.919 Anomalie sortante de configuration (O CONFREJ). Le NAS rejette l'option de rappel.
10:57:17.047 Demande de configuration entrante (I CONFREQ). Le client demande un nouvel ensemble d'options. Notez que le rappel de service Microsoft n'est pas demandé cette fois.
10:57:17.047 Accusé de réception sortant de configuration (O CONFACK). Le NAS reçoit le nouvel ensemble d'options.
10:57:17.047 La négociation LCP de PPP est terminée avec succès. L'état LCP est « s'ouvrent ». Les deux côtés ont reconnu (CONFACK) l'autre demande de configuration de côté (CONFREQ).
10:57:17.047 jusqu'à 10:57:17.191 L'authentification de PPP est terminée avec succès. Après que le LCP négocie, des débuts d'authentification. L'authentification doit avoir lieu avant que tous les protocoles réseau, tels que l'IP, soient fournis. Les deux côtés authentifient avec la méthode négociée pendant le LCP. Montecito authentifie le client utilisant le CHAP.
10:57:20.551 L'état est ouvert pour le protocole de contrôle IP (IPCP). Une artère est négociée et installée pour le pair IPCP, qui est assigné l'adresse IP 1.1.1.1.

Link Control Protocol

Deux types de problèmes sont typiquement produits pendant la négociation LCP.

Le premier se produit quand un pair fait les demandes de configuration que l'autre pair ne peut pas ou ne reconnaîtra pas. Tandis que c'est un cas fréquent, ce peut être un problème si le demandeur insiste sur le paramètre. Un exemple typique est en négociant AUTHTYPE (également connu sous le nom de « AuthProto »). Par exemple, beaucoup de serveurs d'accès sont configurés pour recevoir seulement le CHAP pour l'authentification. Si l'appelant est configuré pour faire seulement l'authentification PAP, CONFREQs et CONFNAKs seront permutés jusqu'à un pair ou aux autres arrêters la connexion.

BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
...
...

Le deuxième type de problème dans LCP est quand seulement CONFREQs sortant sont vus sur un ou les deux pairs comme dans l'exemple ci-dessous. C'est habituellement le résultat de ce qui est mentionné car une non-concordance de vitesse à la couche inférieure. Cette condition peut se produire dans async ou le RNIS DDR.

Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open  
Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25  
Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:57:59.768: As5 LCP: PFC (0x0702)
Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) 
Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 
Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:01.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). 
Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 
Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:03.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) 
Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 

!--- This repeats every two seconds until:

Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 
Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:19.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802)  
Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR

Si la connexion est async, la cause probable est une non-concordance de vitesse entre le routeur et son modem. C'est habituellement en raison de avoir manqué pour verrouiller la vitesse DTE du modem à la vitesse configurée de la ligne TTY. Le problème peut être trouvé sur l'un ou l'autre ou chacun des deux pairs, ainsi vérifiez chacun des deux. Référez-vous au modem ne peut pas envoyer ou recevoir des données plus tôt en ce chapitre.

Si les symptômes sont vus quand la connexion est au-dessus du RNIS, le problème est susceptible d'être qu'un pair se connecte au 56K tandis que l'autre est à 64K. Tandis que cette condition est rare, elle se produit. Le problème a pu être un ou les deux pairs, ou probablement l'opérateur téléphonique. Utilisez le debug isdn q931 et examinez les messages de configuration sur chacun des pairs. La capacité de support envoyée d'un pair devrait apparier la capacité de support vue dans le message de configuration reçu sur l'autre pair. Comme solution possible, configurez la vitesse, le 56K ou le 64K de composition, dans le l'un ou l'autre la carte de commande dialer de niveau d'interface ou dans la vitesse de la commande dialer le RNIS configurée sous un map-class.

*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

Cette situation est une qui peut justifier un appel à Cisco TAC. Collectez les sorties suivantes des deux pairs avant d'appeler le TAC :

  • show running-config

  • show version

  • debug isdn q931

  • debug isdn event

  • debug ppp negotiation

Authentification

L'authentification défaillante est la raison la plus commune simple pour une panne de PPP. Les noms d'utilisateur et mot de passe Misconfigured ou mal adaptés créent des messages d'erreur dans la sortie de débogage.

L'exemple suivant prouve que le nom d'utilisateur Goleta n'a pas une autorisation de se connecter au NAS, qui n'a pas un nom d'utilisateur local configuré pour cet utilisateur. Pour réparer le problème, utilisez la commande de password password de nom de nom d'utilisateur d'ajouter le nom d'utilisateur « Goleta » à la base de données locale de l'AAA du NAS :

Mar 13 11:01:42.399: As2 LCP: State is Open
Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response.  Username Goleta not found
Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure"
Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING

L'exemple suivant prouve que le nom d'utilisateur « Goleta » est configuré sur le NAS. Cependant, la comparaison de mots de passe a manqué. Pour réparer ce problème, utilisez la commande de password password de nom de nom d'utilisateur de spécifier le mot de passe de connexion correct pour Goleta :

Mar 13 11:04:06.843: As3 LCP: State is Open
Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed"
Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING

Pour plus d'informations sur l'authentification PAP référez-vous en configurant et dépannage du Password Authentication Protocol (PAP) de PPP.

Protocole de contrôle de réseau

Après que les pairs aient avec succès exécuté l'authentification priée, la négociation entre dans la phase de NCP. Si les deux pairs sont correctement configurés, la négociation de NCP pourrait ressembler à l'exemple suivant dans lequel affiche un PC client composant et étant en pourparlers avec le NAS :

solvang# show debug
Generic IP:
IP peer address activity debugging is on
PPP:
PPP protocol negotiation debugging is on

*Mar  1 21:35:04.186: As4 PPP: Phase is UP
*Mar  1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
*Mar  1 21:35:04.194: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28
*Mar  1 21:35:04.282: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.286: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:04.290: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:04.298: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar  1 21:35:04.310: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15
*Mar  1 21:35:04.318: As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
*Mar  1 21:35:04.318: As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
*Mar  1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
*Mar  1 21:35:04.326: As4 LCP:  (0x80FD0101000F12060000000111050001)
*Mar  1 21:35:04.330: As4 LCP:  (0x04)
*Mar  1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 21:35:04.338: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4,
 changed state to up
*Mar  1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.278: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:07.282: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:07.286: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.298: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.302: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.310: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.430: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.434: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.442: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2
*Mar  1 21:35:07.450: ip_get_pool: As4: using pool default
*Mar  1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2
*Mar  1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
*Mar  1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.462: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.466: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.474: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.478: As4 IPCP: State is Open
*Mar  1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2

Détails de la négociation de NCP de PPP

Groupe date/heure Description
21:35:04.190 Demande de configuration sortante (O CONFREQ). Le NAS envoie un paquet de requêtes de configuration PPP en sortie contenant son adresse IP au pair.
21:35:04.282 CONFREQ entrant. Les demandes de pair de faire la compression d'en-tête VJ. Il a besoin d'une adresse IP pour lui-même, aussi bien que des adresses des serveurs DNS principaux et secondaires.
21:35:04.306 Config-anomalie sortante (CONFREJ). La compression d'en-tête VJ est rejetée.
21:35:04.314 jusqu'à 21:35:04.330 Le pair envoie une demande de faire le Control Protocol de compactage ; le protocole entier est rejeté par le NAS au moyen d'un message PROTREJ. Le pair ne devrait pas (et ne fait pas) tenter de relancer le CCP.
21:35:04.334 Le pair reconnaît l'adresse IP du NAS avec un CONFACK.
21:35:07.274 CONFREQ entrant. De pair les demandes plus de faire la compression d'en-tête VJ, mais a besoin toujours d'une adresse IP pour elle-même, aussi bien que des adresses des serveurs DNS principaux et secondaires.
21:35:07.294 Le NAS envoie un CONFNAK contenant l'adresse qu'il veut que le pair l'utilise, et des adresses des serveurs DNS principaux et secondaires.
21:35:07.426 Le pair envoie les adresses de nouveau au NAS ; une tentative de confirmer que les adresses ont été correctement reçues.
21:35:07.458 Le NAS reconnaît les adresses avec un CONFACK.
21:35:07.478 Chaque côté de la connexion ayant émis un CONFACK, négociation termine. Les interfaces Async4 d'exposition de commande sur le NAS affiche « IPCP : Ouvrez-vous ».
21:35:07.490 Une route hôte au pair distant est installée dans la table du routage du NAS.

Il est possible que les pairs négocient simultanément plus d'un protocole de la couche 3. Il n'est pas rare, par exemple, pour voir l'IP et l'IPX étant négociés. Il est également possible que un protocole négocie avec succès tandis que l'autre ne fait pas ainsi.

Dépannage du NCP

Tous les problèmes qui se posent pendant la négociation de NCP peuvent typiquement être tracés aux configurations des pairs de négociation. Si la négociation PPP échoue pendant la phase de NCP, référez-vous aux étapes suivantes :

  1. Vérifiez la configuration de protocole d'interface

    Examinez la sortie de la commande show running-config de privileged exec. Vérifiez que l'interface est configurée pour prendre en charge le protocole que vous souhaitez exécuter plus de la connexion.

  2. Vérifiez l'adresse d'interface

    Confirmez que l'interface en question a une adresse configurée. Si utilisant l'ip unnumbered [interface-nom] ou le bouclage d'ipx ppp-client [nombre], assurez-vous que l'interface référencée est configurée avec une adresse.

  3. Vérifiez la disponibilité d'adresse client

    Si le NAS est censé émettre une adresse IP à l'appelant, assurez-vous qu'une telle adresse est disponible. L'adresse IP à distribuer à l'appelant peut être obtenue par une des méthodes suivantes :

    • Configurez localement sur l'interface. Vérifiez la configuration d'interface pour le peer default ip address a.b.c.d. de commande dans la pratique, cette méthode devrait seulement être utilisé sur les interfaces qui reçoivent des connexions d'un appelant simple, tel qu'en fonction une interface async (pas d'un group-async).

    • Pool d'adresses localement configuré sur le NAS. L'interface devrait avoir le groupe de peer default ip address de commande [nom du pool]. En outre, le groupe doit être défini au niveau du système avec l'ip local pool de commande [nom du pool] [premier-adresse] [dernier-adresse]. La plage d'adresses définie dans le groupe devrait être assez étendue pour rendre service à autant d'appelants simultané-connectés car le NAS est capable.

    • Serveur DHCP. L'interface de NAS doit être configurée avec le peer default ip address dhcp de commande. En outre, le NAS doit être configuré pour indiquer un serveur DHCP avec l'ip dhcp server de commande de configuration globale [adresse].

    • AAA. Si utilisant TACACS+ ou RAYON pour l'autorisation, le serveur d'AAA peut être configuré pour remettre une adresse IP spécifique à un appelant donné chaque fois que l'appelant connecte. Voir le pour en savoir plus du chapitre 16.

  4. Vérifiez la configuration d'adresse du serveur

    Pour renvoyer les adresses configurées des serveurs de Domain Name Server ou de Windows NT en réponse aux demandes BOOTP, assurez-vous que le dns-server niveau global d'async-bootp de commandes [adresse] et des nbns-server d'async-bootp [adresse] sont configurées.

    Remarque: Tandis que le subnet mask d'async-bootp de commande [masque] peut être configuré sur le NAS, le masque de sous-réseau ne sera pas négocié entre le NAS et un PC de client entrant de PPP. En raison de la nature des connexions point-à-point, le client utilise automatiquement l'adresse IP du NAS (appris pendant la négociation IPCP) comme passerelle par défaut. Le masque de sous-réseau n'est pas nécessaire dans cet environnement point par point. Le PC sait que si l'adresse de destination n'apparie pas l'adresse locale, le paquet devrait être expédié à la passerelle par défaut (NAS) qui est toujours atteinte par l'intermédiaire du lien de PPP.

Avant d'appeler l'équipe de Cisco Systems TAC

Avant d'appeler le centre d'assistance technique de Cisco Systems (TAC), veillez-vous pour avoir lu par ce chapitre et pour s'être terminé les actions suggérées pour votre problème de système.

Supplémentaire, faites le suivant et documentez les résultats de sorte que nous puissions mieux vous aider :

Pour tous les problèmes, collectez la sortie du show running-config et du show version. Assurez-vous que les horodateurs de service de commande mettent au point la milliseconde date-heure est dans la configuration.

Pour des problèmes DDR, collectez ce qui suit :

  • show dialer map

  • mettez au point le numéroteur

  • debug ppp negotiation

  • debug ppp authentication

Si le RNIS est impliqué, collectez :

  • état de show isdn

  • debug isdn q931

  • debug isdn event

Si les Modems sont impliqués, collectez :

  • shows line

  • show line [x]

  • show modem (si les modems intégrés sont impliqués)

  • show modem version (si les modems intégrés sont impliqués)

  • debug modem

  • debug modem csm (si les modems intégrés sont impliqués)

  • mettez au point la conversation (si un scénario DDR)

Si T1 ou PRIs sont impliqué, collectez :

  • t1 de show controller

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 10203