Contenu

Introduction

Organigramme

Dépannage : Comment se connecter et capturer ces débogages

Dépannage : Le routeur tente-t-il de composer le numéro ?

Symptôme : Le routeur ne tente pas de composer le numéro

Aucune sortie de débogage du tout

Il y a une sortie de débogage mais aucun message « Tentative de numérotation »

Exemple 1

Exemple 2

Exemple 3

Dépannage : L’appel RNIS se connecte-t-il correctement ?

Symptôme : L'appel RNIS ne se connecte pas correctement

Dépannage : La phase PPP LCP a-t-elle abouti ?

Symptôme : La phase PPP LCP n'a pas réussi

Cause possible: PPP n'est pas configuré

Cause possible: Non-correspondance de vitesse RNIS

Cause possible: Les deux routeurs ne sont pas d'accord sur un protocole d'authentification (CHAP ou PAP) à utiliser

Dépannage : L’authentification PPP réussit-elle ?

Symptôme : L'authentification PPP échoue

Exemple 1

Exemple 2

Exemple 3

Dépannage : La phase PPP NCP (IPCP) est-elle terminée ?

Symptôme : La négociation PPP NCP (IPCP) n'aboutit pas

Problème : Échec de la négociation d'adresse IP

Problème : Le routeur appelé échoue à la liaison de profil de numéroteur

Problèmes post-connexion

Symptôme : L'appel se déconnecte prématurément ou l'appel ne se déconnecte pas du tout

Symptôme : Le routeur compose régulièrement la connexion

Symptôme : Le deuxième canal B ne se connecte pas

Problèmes de connectivité IP

Informations connexes

Introduction

Ce document vous aide à dépanner l'accès commuté à l'interface BRI (Basic Rate Interface) RNIS. Dans l'organigramme et l'exemple de résultat ci-dessous, nous avons configuré une connexion RNIS BRI à une autre à l'aide des profils de numérotation. Cependant, les mêmes étapes de dépannage s'appliquent aux connexions à d'autres routeurs (tels que les filiales) et lors de l'utilisation du routage DDR (Dial-on-Demand Routing) hérité.

Note: Vous pouvez également utiliser la communauté d'assistance Cisco afin de vous aider à résoudre votre problème RNIS.

Pour obtenir des informations d'introduction sur RNIS et DDR, reportez-vous à la formation audio disponible dans la section Cisco Learning Connection.

Organigramme

Cliquez sur un lien ci-dessous pour obtenir plus d'informations sur l'objet. Utilisez le bouton Précédent de votre navigateur pour revenir à cet organigramme.

Dépannage : Comment se connecter et capturer ces débogages

Vous pouvez vous connecter à votre routeur via le câble de console connecté au port série de votre ordinateur ou via Telnet.

Si vous devez vous connecter à votre routeur via la console, reportez-vous à la section Application des paramètres corrects de l'émulateur de terminal pour les connexions de console. Si votre routeur est déjà configuré pour la connectivité sur Ethernet et que vous souhaitez vous connecter à votre routeur à l'aide de telnet, utilisez simplement un client Telnet pour vous connecter à l'adresse IP Ethernet du routeur.

Dans tous les cas (console ou telnet), il est préférable d'utiliser un client qui vous permet de conserver un historique des sorties reçues pendant la session, car vous devrez peut-être faire défiler la sortie de débogage pour rechercher des messages particuliers.

Activez des millisecondes sur la sortie de débogage et les messages de journal. Lorsque vous y êtes invité, entrez le mot de passe configuré sur votre routeur et passez en mode enable :

router>enable

Password: (enter the enable password)

router#

router#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

router(config)#service timestamps debug datetime msec

router(config)#service timestamps log datetime msec

Si vous êtes connecté à l'aide de telnet, tapez terminal monitor comme suit :

router#terminal monitor

router#

Ensuite, entrez les commandes debug ci-dessous :

router#debug isdn q931

ISDN Q931 packets debugging is on

router#debug ppp negotiation

PPP protocol negotiation debugging is on

router#debug dialer packet

Dial on demand packets debugging is on

router#debug dialer

Dial on demand events debugging is on

router#debug ppp authentication

PPP authentication debugging is on

router#

Lancez ensuite la requête ping sur le routeur appelant. Voici un exemple de résultat de débogage d'un appel réussi. Les différentes phases, telles qu'elles sont identifiées dans l'organigramme, sont mises en évidence.

router#ping 194.183.201.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds:

*Mar  1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),

100 bytes, outgoing interesting (ip PERMIT)

! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1)

*Mar  1 00:06:36.387: BR0 DDR: rotor dialout [priority]

*Mar  1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1)

*Mar  1 00:06:36.395: BR0 DDR: Attempting to dial 8134

! -- Number used to dial.

! -- This is configured using the dialer string or dialer map command

! -- If you do not see this message proceed to section

! -- Symptom: The Router Does Not Attempt to Dial

*Mar  1 00:06:36.411: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x02

*Mar  1 00:06:36.415:         Bearer Capability i = 0x8890

*Mar  1 00:06:36.423:         Channel ID i = 0x83

*Mar  1 00:06:36.427:         Called Party Number i = 0x80, '8134',

Plan:Unknown, Type:Unknown

*Mar  1 00:06:36.519: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x82

*Mar  1 00:06:36.527:         Channel ID i = 0x89

*Mar  1 00:06:36.727: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x82

*Mar  1 00:06:36.743: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x02

*Mar  1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

! -- ISDN Layer 3 CONNECT message and Link Up message

! -- If you do not see this message proceed to section

! -- Symptom: The ISDN Call Does Not Connect Successfully

*Mar  1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo

*Mar  1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1

*Mar  1 00:06:36.787: BR0:1 PPP: Treating connection as a callout

*Mar  1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open

! -- LCP negotiation begins

*Mar  1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out

*Mar  1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10

*Mar  1 00:06:36.799: BR0:1 LCP:    MagicNumber 0x0012586A (0x05060012586A)

*Mar  1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15

*Mar  1 00:06:36.863: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

*Mar  1 00:06:36.867: BR0:1 LCP:    MagicNumber 0x10D36A4C (0x050610D36A4C)

*Mar  1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15

*Mar  1 00:06:36.875: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

*Mar  1 00:06:36.875: BR0:1 LCP:    MagicNumber 0x10D36A4C (0x050610D36A4C)

*Mar  1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10

*Mar  1 00:06:36.883: BR0:1 LCP:    MagicNumber 0x0012586A (0x05060012586A)

*Mar  1 00:06:36.887: BR0:1 LCP: State is Open

! -- LCP negotiation is complete. Any LCP state other than Open indicates

! -- that LCP negotiation has failed.

! -- If you do not see this message proceed to section

! -- Symptom: PPP LCP Phase Does Not Succeed

*Mar  1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer

*Mar  1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP"

! -- Incoming CHAP challenge

*Mar  1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX

! -- Using alternate hostname configured with ppp chap hostname command

*Mar  1 00:06:36.915: BR0:1 CHAP: Username ISP not found

*Mar  1 00:06:36.919: BR0:1 CHAP: Using default password

! -- Using password configured with ppp chap password command

*Mar  1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX"

! -- Sending response from "XXXXX" which is the alternate hostname for the router

*Mar  1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4

! -- NAS has succesfully authenticated the router

*Mar  1 00:06:36.943: BR0:1 PPP: Phase is UP

! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins

*Mar  1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10

*Mar  1 00:06:36.951: BR0:1 IPCP:    Address 0.0.0.0 (0x030600000000)

! -- This router does not have an address configured, so it sends a

! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address

! -- which is accomplished by the sending of a CONFNAK with the proper address.

*Mar  1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10

*Mar  1 00:06:36.963: BR0:1 IPCP:    Address 194.183.201.1 (0x0306C2B7C901)

! -- Incoming CONFREQ indicating the peer's IP address

*Mar  1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10

*Mar  1 00:06:36.971: BR0:1 IPCP:    Address 194.183.201.1 (0x0306C2B7C901)

! -- The router accepts the peer's IP address

! -- (since it is not trying to assign one to the peer)

! -- Once the call is connected a route to this address will be installed

*Mar  1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10

*Mar  1 00:06:36.979: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)

! -- The peer CONFNAKs our initial Address request of 0.0.0.0

! -- It responds with the address that this router could use

! -- The NAS can assign this using the peer default ip address or dialer map command

*Mar  1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10

*Mar  1 00:06:36.987: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)

! -- This router requests the address previously suggested by the NAS

*Mar  1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10

*Mar  1 00:06:37.015: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)

! -- NAS accepts the address requested by the client

*Mar  1 00:06:37.015: BR0:1 IPCP: State is Open

! -- PPP NCP (IPCP) negotiation is complete

! -- If you do not see this message proceed to section

! -- Symptom: PPP NCP (IPCP) negotiation does not succeed

*Mar  1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address

194.183.201.2

*Mar  1 00:06:37.031: BR0:1 DDR: dialer protocol up

*Mar  1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1

! -- Route to peer is installed

*Mar  1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,

changed state to up

*Mar  1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,

outgoing interesting (ip PERMIT)

*Mar  1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,

outgoing interesting (ip PERMIT)

*Mar  1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,

outgoing interesting (ip PERMIT)

*Mar  1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,

outgoing interesting (ip PERMIT)

router#

*Mar  1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134

unknown

router#

Revenir à l'organigramme du dépannage

Dépannage : Le routeur tente-t-il de composer le numéro ?

Afin de déterminer si le routeur tente de passer un appel, vérifiez si vous avez les lignes suivantes dans la sortie de débogage du routeur appelant :

*Mar  1 00:06:36.395: BR0 DDR: Attempting to dial 8134

Dans le résultat du débogage, 8134 est le numéro de répertoire RNIS que le routeur tente de composer. Ce numéro a été spécifié à l'aide de la commande dialer string ou dialer map.

Revenir à l'organigramme du dépannage

Symptôme : Le routeur ne tente pas de composer le numéro

Si votre routeur n'essaie pas de composer un numéro, plusieurs possibilités s'offrent à vous :

Aucune sortie de débogage du tout

S'il n'y a aucune sortie de débogage, c'est probablement parce que le paquet IP que vous envoyez n'est même pas routé vers l'interface de numérotation. Les causes les plus courantes sont les suivantes :

- Vérifiez que le protocole IP est configuré sur l'interface de numérotation. Vous devez disposer d'une adresse IP sur l'interface de numérotation ou d'une interface ip non numérotée (où interface est une interface up/up telle qu'ethernet x, loopback x etc) ou adresse ip négociée (si le client obtient une adresse IP du NAS). Si vous utilisez le DDR hérité, l'adresse IP doit être configurée sur l'interface physique (par exemple, l'interface BRI 0).

- Vérifiez que la commande ip routing est configurée. Lorsque vous examinez votre configuration à l'aide de la commande show running-config, vous ne devriez pas voir la commande no ip routing.

- Vérifiez qu'il existe une route statique pointant vers l'interface de numérotation ou le saut suivant (si vous utilisez des mappages de numérotation).
L'exemple suivant (pour le profil de numérotation) est une route statique pour 172.22.53.0/24 avec le saut suivant Dialer 1 :

maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1

L'exemple suivant (pour le routage DDR traditionnel) est une route statique pour 172.22.53.0/24 avec le tronçon suivant 172.16.1.1. L'adresse de tronçon suivant doit correspondre à l'adresse IP de l'instruction dialer map utilisée pour la numérotation :

maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1

- Vérifiez que le numéroteur ou l'interface physique n'est pas en mode administrativement arrêté ou en veille. Utilisez la commande show interface dialer X ou show interface briX pour vous assurer que l'interface est à l'état up/up (usurpation).

Si l'interface est désactivée administrativement, utilisez la commande no shutdown en mode de configuration d'interface.

Si l'interface est en veille, le numéroteur ou l'interface BRI est une sauvegarde d'une connexion active. Vous pouvez supprimer la commande backup interface sous l'interface principale ou tirer le câble de l'interface principale.

Il y a une sortie de débogage mais aucun message « Tentative de numérotation »

Dans ce cas, il y a probablement un paquet IP routé vers l'interface, mais le routeur le rejette et ne lance pas l'appel pour une raison quelconque. Regardez la sortie debug afin de savoir pourquoi la tentative d'appel n'est pas faite. Voici quelques exemples de sorties de débogage et leurs raisons possibles :

Exemple 1

*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1),

100 bytes, outgoing uninteresting (list 101).

Le trafic généré ne correspond pas à la définition de trafic intéressante. Pour cet exemple, modifiez access-list 101.

Une définition de trafic simple et intéressante serait d'autoriser tout le trafic IP comme dans :

maui-soho-01(config)#dialer-list 1 protocol ip permit

Avertissement : Marquer tout le trafic IP comme intéressant peut entraîner le maintien indéfini de la liaison RNIS, en particulier si vous disposez d'un protocole de routage ou d'un autre trafic périodique. Ajustez la définition de trafic intéressante à vos besoins.

Pour plus d'informations sur le trafic intéressant, reportez-vous au document Dialup Technology : Présentation et explications.

Exemple 2

*Mar  1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),

100 bytes, outgoing uninteresting (no dialer-group defined).

Aucun groupe de numérotation n'est configuré sur l'interface de numérotation. Ajoutez un groupe de numérotation comme dans l'exemple suivant :

interface Dialer1

dialer-group X

Note: La valeur de X doit être identique à celle utilisée avec la commande dialer-list.

Exemple 3

*Mar  1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),

100 bytes, outgoing uninteresting (dialer-list 1 not defined).

Il existe une instruction dialer-group sur l'interface de numérotation, mais la liste de numérotation mentionnée n'existe pas. Configurez la liste de numérotation comme dans l'exemple suivant :

dialer-list X protocol ip permit

Note: La valeur de X doit être identique à celle utilisée avec la commande dialer-group sous l'interface de numérotation.

Exemple 4

*Mar  1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),

100 bytes, outgoing interesting (ip PERMIT)

*Mar  1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.

Dans ce cas, le paquet sortant doit être considéré comme suffisamment intéressant pour activer la liaison, mais aucune interface physique n'est disponible pour passer l'appel. Assurez-vous que dialer pool-member X est configuré dans l'interface physique et que dialer pool X est configuré dans l'interface Dialer. Exemple :

interface BRI0

dialer pool-member 1

!

interface Dialer1

dialer pool 1

Vérifiez également que l'interface BRI n'est pas en état d'arrêt.

Exemple 5

*Mar  1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),

100 bytes, outgoing interesting (ip PERMIT)

*Mar  1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.

Dans ce cas, aucune chaîne de numérotation n'est configurée sur l'interface de numérotation. Le routeur souhaite passer un appel mais ne connaît pas le numéro de répertoire RNIS à appeler. Définissez une chaîne de numérotation :

interface Dialer1

dialer string 8134

Pour plus d'informations sur le dépannage, reportez-vous à la section « Le routeur appelant n'envoie pas de message SETUP » du document Dépannage de la couche 3 BRI RNIS à l'aide de la commande debug isdn q931.

Revenir à l'organigramme du dépannage

Dépannage : L’appel RNIS se connecte-t-il correctement ?

Afin d'identifier si l'appel RNIS se connecte, recherchez un message CONNECT_ACK et %LINK-3-UPDOWN dans les débogages :

*Mar  1 00:06:36.743: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x02

*Mar  1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

Si ce message s'affiche, votre appel RNIS est correctement connecté et vous pouvez passer à l'étape suivante. Si vous ne voyez pas de message comme celui-ci, lisez ci-dessous pour connaître les causes possibles.

Revenir à l'organigramme du dépannage

Symptôme : L'appel RNIS ne se connecte pas correctement

1. Si le résultat est similaire à celui-ci, vérifiez que le câble RNIS est branché à la fois sur le routeur et sur la prise Telco.
*Mar  1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4),

100 bytes, outgoing interesting (ip PERMIT)

*Mar  1 21:31:18.190: BR0 DDR: rotor dialout [priority]

*Mar  1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4)

*Mar  1 21:31:18.198: BR0 DDR: Attempting to dial 8134.

*Mar  1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4),

100 bytes, outgoing interesting (ip PERMIT).

*Mar  1 21:31:26.226: ISDN BR0: Could not bring up interface

*Mar  1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E

*Mar  1 21:31:26.246: ISDN BR0: Could not bring up interface.

Success rate is 0 percent (0/5)

2. Vérifiez que le circuit RNIS fonctionne correctement. Utilisez la commande show isdn status pour vérifier que la couche 1 est ACTIVE, que la couche 2 est MULTIPLE_FRAME_ESTABLISHED et que les SPID (si nécessaire) sont valides. Pour plus d'informations, reportez-vous au document Utilisation de la commande show isdn status pour le dépannage BRI.

Si vous disposez de la sortie d'une commande show isdn status de votre périphérique Cisco, vous pouvez utiliser Cisco CLI Analyzer pour afficher les problèmes potentiels et les correctifs. Pour utiliser Cisco CLI Analyzer, vous devez être un utilisateur enregistré, être connecté et avoir JavaScript activé.

3. Vérifiez que la chaîne de numérotation RNIS configurée est correcte. N'oubliez pas que vous devrez peut-être ajouter un zéro, neuf ou d'autres chiffres avant de pouvoir obtenir une ligne extérieure lorsque vous êtes connecté via un PBX.

4. Si la connexion utilise un opérateur longue distance, contactez votre opérateur téléphonique local et votre fournisseur longue distance pour vérifier que le service est activé. Souvent, le circuit RNIS de la compagnie de téléphone locale est mal configuré de sorte que les appels longue distance RNIS sortants ne soient pas commutés vers le réseau du fournisseur d’accès longue distance approprié. Vous devez également vérifier que le réseau des fournisseurs de services longue distance fonctionne.

Aux États-Unis, et dans les situations où l'opérateur de téléphonie ou le fournisseur de services longue distance n'est pas en mesure de résoudre le problème, vous pouvez utiliser un opérateur de téléphonie intercirconscriptions préabonné (PIC). Les codes PIC sont des préfixes à sept chiffres qui identifient les transporteurs interurbains américains aux entreprises de services locaux (LEC). Cela permet aux clients d'utiliser différents opérateurs longue distance pour des appels individuels. Le code PIC est configuré comme préfixe au numéro composé. La plupart des PIC sont au format 1010xxx.

Utilisez no dialer string xxxxx ou no dialer map pour supprimer le numéro existant, puis configurez le nouveau numéro.

Par exemple, la chaîne de numérotation 10103215125551111.

5. Recherchez un message de déconnexion RNIS.

Le logiciel Cisco IOS® décode le code de cause dans ce message de déconnexion et vous donne un message texte clair qui contient souvent des informations utiles à la cause du problème. Vous trouverez ici les chaînes suivantes :

- Numéro non alloué ou non affecté

- Destination incompatible (les deux indiquent que le numéro composé est peut-être incorrect)

- Nombre occupé (ce qui indique que le côté appelé est occupé)

- Panne temporaire (ce qui indique une panne temporaire sur le réseau Telco)

Afin de trouver la raison possible d'une cause de déconnexion spécifique, référez-vous à Comprendre les codes de cause de déconnexion debug isdn q931.

Par exemple, une déconnexion due à un numéro RNIS incorrect peut être indiquée par :

*Mar  3 00:10:38.756: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0xEB

*Mar  3 00:10:38.764:         Cause i = 0x84D8 - Incompatible destination

En référence au document Codes de cause de déconnexion mentionné précédemment, nous pouvons déterminer que le code de déconnexion a été provoqué par une tentative de connexion à un équipement non RNIS (par exemple, une ligne analogique).

Une déconnexion due à un numéro mal formaté peut être indiquée avec :

Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86

Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format

(incomplete number)

En référence au document Compréhension des codes de cause de déconnexion debug isdn q931, nous pouvons déterminer que le code de déconnexion a été causé par un format non valide pour le numéro RNIS distant. La connexion échoue car l'adresse de destination est présentée (au commutateur) dans un format non reconnaissable, ou l'adresse de destination est incomplète.

L'exemple suivant illustre un appel rejeté en raison d'un numéro RNIS incorrect :

*Mar 13 11:29:04.758: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x83

*Mar 13 11:29:04.769:         Cause i = 0x8295 - Call rejected

6. Si votre opérateur téléphonique vous a fourni des identificateurs de profil de service (SPID) à utiliser, assurez-vous que ces SPID sont configurés sur l'interface BRI. Les SPID sont généralement utilisés uniquement aux États-Unis et avec les types de commutateurs NI et DMS (les types de commutateurs 5ess n'ont pas besoin de SPID).
interface BRI0

isdn spid1 51255511110101 5551111

isdn spid2 51255511120101 5551112

Vous pouvez utiliser la commande show isdn status pour vérifier si les SPID sont corrects.

Pour plus d'informations, reportez-vous au document Dépannage des SPID RNIS BRI.

Si vous disposez de la sortie d'une commande show isdn status à partir de votre périphérique Cisco, vous pouvez utiliser Cisco CLI Analyzer pour afficher les problèmes potentiels et les correctifs. Pour utiliser Cisco CLI Analyzer, vous devez être un utilisateur enregistré, être connecté et avoir JavaScript activé.

7. Si la procédure ci-dessus n'a pas résolu le problème, utilisez le document Dépannage de la couche 3 BRI RNIS à l'aide de la commande debug isdn q931 pour plus de dépannage.

Revenir à l'organigramme du dépannage

Dépannage : La phase PPP LCP a-t-elle abouti ?

Dans la sortie de débogage, une ligne de message doit s'afficher pour les éléments suivants :

*Mar  1 00:06:36.887: BR0:1 LCP: State is Open

Si vous voyez cette ligne, cela indique que le protocole LCP (Link Control Protocol) a été négocié avec succès. Tout état autre que ouvert indique que le protocole LCP a échoué.

Revenir à l'organigramme du dépannage

Symptôme : La phase PPP LCP n'a pas réussi

Cause possible: PPP n'est pas configuré

Si vous avez une sortie de débogage similaire aux lignes suivantes, cela indique que PPP n'a pas démarré.

*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up.

*Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100

bytes, outgoing interesting (ip PERMIT).

*Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100

bytes, outgoing interesting (ip PERMIT).

*Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100

bytes, outgoing interesting (ip PERMIT)

*Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now

connected to 8101.

! -- Call connects but the router does not send any PPP CONFREQ packets

*Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100

bytes, outgoing interesting (ip PERMIT).

Success rate is 0 percent (0/5)

Notez dans le résultat du débogage que le routeur n’envoie aucun message PPP CONFREQ. Ceci est probablement dû au fait que l’interface n’a pas été configurée pour l’encapsulation PPP.

Dans ce cas, vérifiez que vous avez configuré la commande encapsulation ppp sous l'interface de numérotation et l'interface physique. Voici quelques exemples :

interface Dialer1

encapsulation ppp

or

interface BRI 0

encapsulation ppp

Cause possible: Non-correspondance de vitesse RNIS

Parfois, vous pouvez voir uniquement des messages CONFREQ LCP sortants, mais aucun message LCP entrant. Voici un exemple :

*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

! -- Call is connected. PPP negotiation will begin

*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.

*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout

*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open

[0 sess, 0 load]

! -- PPP negotiation begins

*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15

*Mar 14 01:49:10.200: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

*Mar 14 01:49:10.204: BR0:1 LCP:    MagicNumber 0x545D708A (0x0506545D708A).

! -- Outgoing Configure-Request (CONFREQ)

*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent

! -- Router has not received a CONFREQ from the peer, hence the timeout

*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15

*Mar 14 01:49:12.184: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

*Mar 14 01:49:12.188: BR0:1 LCP:    MagicNumber 0x545D708A (0x0506545D708A).

*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent

*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15

*Mar 14 01:49:14.168: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

*Mar 14 01:49:14.172: BR0:1 LCP:    MagicNumber 0x545D708A (0x0506545D708A)

Ce problème peut être causé par :

- L'extrémité distante n'est pas configurée pour PPP. Configurez la commande encapsulation ppp sur l'extrémité distante

- Paquets ne passant pas par le support de transmission. La cause la plus courante de cette situation est une non-correspondance de vitesse RNIS

La nature du problème, du point de vue de la technologie RNIS, est qu'un côté se connecte probablement à 56 k alors que l'autre côté se connecte à 64 k. Il est possible que le circuit local ou distant ne prenne pas en charge les connexions 64K par défaut. Essayez de configurer les deux extrémités pour qu'elles fonctionnent à 56 Ko.

Pour les profils de numérotation :

maui-soho-01(config)#interface Dialer1

maui-soho-01(config-if)#dialer string 81560 class 56k

! -- Dial 81560 and use the map-class named "56k" (defined below)

maui-soho-01(config-if)#exit

maui-soho-01(config)#map-class dialer 56k

! -- map-class named "56k" that was used with the dialer string

! -- in int Dialer1

maui-soho-01(config-map-clas)#dialer isdn speed 56

! -- Set the speed of the call to be 56k (default is 64k)

Pour DDR hérité (cartes de numérotation) :

maui-soho-01(config)#interface bri 0

maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560

!-- The keyword speed 56 sets the outgoing call rate at 56k

Cause possible: Les deux routeurs ne sont pas d'accord sur un protocole d'authentification (CHAP ou PAP) à utiliser

Si vous disposez d'une sortie de débogage similaire aux lignes suivantes, cela indique que votre routeur et le côté distant n'ont pas convenu d'un protocole d'authentification à utiliser :

*Mar  1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14

*Mar  1 00:07:24.055: BR0:1 LCP:    AuthProto PAP (0x0304C023)

*Mar  1 00:07:24.059: BR0:1 LCP:    MagicNumber 0x1110C3C5 (0x05061110C3C5)

! -- An incoming CONFREQ (Config-Request) indicating the peer is

! -- willing to do PAP

*Mar  1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9

*Mar  1 00:07:24.063: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP

! -- The router suggests CHAP instead

*Mar  1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14

*Mar  1 00:07:24.091: BR0:1 LCP:    AuthProto PAP (0x0304C023)

*Mar  1 00:07:24.091: BR0:1 LCP:    MagicNumber 0x1110C3C5 (0x05061110C3C5)

! -- The peer once again requests PAP

! -- This is probably because PAP is the only protocol configured on the peer

! -- The router will once again CONFNAK PAP and suggest CHAP

*Mar  1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9

*Mar  1 00:07:24.099: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

! -- The router NAKs PAP and suggests CHAP for the 2nd time

*Mar  1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4

*Mar  1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4

! -- The two routers cannot agree on LCP parameters so the call is disconnected

Dans ce cas, vérifiez que vous avez configuré les éléments suivants :

interface Dialer1

encapsulation ppp

ppp authentication chap pap callin

! -- This permits both CHAP and PAP and one-way authentication

Pour plus d'informations sur le protocole CHAP (Challenge Handshake Authentication Protocol) ou le protocole PAP (Password Authentication Protocol), reportez-vous aux documents suivants :

- Présentation et configuration de l'authentification PPP CHAP

- Authentification PPP par le biais des commandes ppp chap hostname et ppp authentication chap callin

- Configuration et dépannage du protocole PAP (Password Authentication Protocol) pour PPP

Vous pouvez également utiliser la communauté d'assistance Cisco pour le dépannage PPP.

Revenir à l'organigramme du dépannage

Dépannage : L’authentification PPP réussit-elle ?

Vérifiez la sortie de débogage pour une ligne similaire à ceci :

*Mar  1 00:06:36.943: BR0:1 PPP: Phase is UP

Revenir à l'organigramme du dépannage

Symptôme : L'authentification PPP échoue

Vérifiez que vous avez configuré les lignes suivantes :

interface Dialer1

ppp chap hostname XXXXX

ppp chap password YYYYY

ppp pap sent-username XXXXX password YYYYY

Dans l'exemple, XXXXX est votre nom d'utilisateur et YYYY votre mot de passe.

Note: Configurez uniquement le nom d'utilisateur et le mot de passe pour la méthode d'authentification que vous et votre homologue employez. Par exemple, si vous n'utilisez pas PAP tous les deux, vous n'avez pas besoin de la commande ppp pap sent-username. Cependant, si vous n'êtes pas certain que l'homologue prend en charge PAP ou CHAP, configurez les deux.

Selon la version et la configuration de votre logiciel Cisco IOS, le mot de passe peut apparaître chiffré dans votre configuration. Si c'est le cas, lorsque vous exécutez une commande show running-configuration, vous voyez le mot « password » suivi du chiffre 7, puis une séquence de nombres, comme dans l'exemple suivant :

interface Dialer1

ppp chap password 7 140005

Dans ce cas, vous ne pouvez pas vérifier si le mot de passe configuré est correct ou non en examinant la configuration. Pour vous assurer que le mot de passe est correct, passez simplement en mode de configuration et supprimez et configurez à nouveau le mot de passe. Pour identifier un échec de mot de passe dans le débogage, comparez votre résultat de débogage avec l'exemple de résultat ci-dessous.

Si ce routeur authentifie l'homologue, assurez-vous de configurer la commande username username password password, où username est le nom fourni par le routeur homologue pour l'authentification.

Exemple 1

Un message comme celui ci-dessous signifie que le mot de passe CHAP n'est pas valide.

*Mar  1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP"

! -- Incoming CHAP challenge

*Mar  1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX

! -- Using alternate hostname configured with ppp chap hostname command

*Mar  1 00:16:54.411: BR0:1 CHAP: Username ISP not found

*Mar  1 00:16:54.415: BR0:1 CHAP: Using default password

! -- Using password configured with ppp chap password command

*Mar  1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX"

! -- Sending response from "XXXXX" which is the alternate hostname for the router

*Mar  1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is

"MD/DES compare failed"

! -- Incoming CHAP failure. The remote router failed to authenticate this router.

! -- Check the username and password configured on both routers

*Mar  1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4

*Mar  1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4

Astuce : Échec CHAP entrant (indiqué par CHAP : I FAILURE) signifie que l'homologue n'a pas pu authentifier le routeur. Utilisez debug ppp negotiation sur le routeur homologue pour déterminer la cause exacte de l'échec.

Pour plus d'informations, reportez-vous au document Authentification PPP à l'aide des commandes ppp chap hostname et ppp authentication chap callin.

Exemple 2

Un message comme celui ci-dessous peut signifier que le nom d'utilisateur CHAP n'est pas valide :

*Mar  1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP"

! -- Incoming CHAP challenge

*Mar  1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw

! -- Using alternate hostname configured with ppp chap hostname command

*Mar  1 00:18:34.839: BR0:1 CHAP: Username ISP not found

*Mar  1 00:18:34.839: BR0:1 CHAP: Using default password

! -- Using password configured with ppp chap password command

*Mar  1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw"

! -- Sending response from "Xdwqdqw" which is the alternate hostname

! -- for the router

*Mar  1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26

msg is "Authentication failure"

! -- Incoming CHAP failure. The remote router failed to authenticate

! -- this router. Check the username and password configured on both routers

*Mar  1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4

*Mar  1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4

Astuce : Échec CHAP entrant (indiqué par CHAP : I FAILURE) signifie que l'homologue n'a pas pu authentifier le routeur. Utilisez debug ppp negotiation sur le routeur homologue pour déterminer la cause exacte de l'échec.

Pour plus d'informations, référez-vous au document Authentification PPP à l'aide des commandes ppp chap hostname et ppp authentication chap callin.

Exemple 3

Un message comme ci-dessous signifie que le mot de passe PAP n'est pas valide :

*Mar  1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX"

! -- Outgoing PAP Authentication Request from XXXXX

! -- XXXXX is the username configured in

! -- ppp pap sent-username XXXXX password YYYYY

*Mar  1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is

"Authentication failure"

! -- An incoming PAP failure. The peer could not authenticate this router

! -- Verify that the username and password configured on both routers

! -- are identical

*Mar  1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4

*Mar  1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4

*Mar  1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING

Pour plus d'informations, reportez-vous au document Configuration et dépannage du protocole PAP (PPP Password Authentication Protocol).

Exemple 4

Un message comme ci-dessous signifie que le nom d'utilisateur PAP n'est pas valide :

*Mar  1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer

*Mar  1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew"

! -- Outgoing PAP Authentication Request from ewddew

! -- ewddew is the username configured in

! -- ppp pap sent-username ewddew password YYYYY

*Mar  1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27

msg is "Authentication failure"

! -- An incoming PAP failure. The remote router could not authenticate

! -- this router. Check the username and password configured on both routers

! -- Note the PAP authentication failure in example 3 and 4 are identical.

! -- Hence the only way to determine if the username, password or both are

! -- wrong is to run debug ppp negotiation on the authenticating router

*Mar  1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4

*Mar  1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4

*Mar  1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING

Pour plus d'informations, reportez-vous au document Configuration et dépannage du protocole PAP (PPP Password Authentication Protocol).

Vous pouvez également utiliser la communauté d'assistance Cisco pour plus de dépannage PPP.

Revenir à l'organigramme du dépannage

Dépannage : La phase PPP NCP (IPCP) est-elle terminée ?

L'élément clé négocié dans IPCP est l'adresse de chaque homologue. Avant la négociation IPCP, chaque homologue se trouve dans l'un des deux états possibles ; soit il a une adresse IP, soit il ne l'a pas. Si l'homologue a déjà une adresse, il envoie cette adresse dans un CONFREQ à l'autre homologue. Si l'adresse est acceptable pour l'autre homologue, un CONFACK est retourné. Si l'adresse n'est pas acceptable, la réponse est une CONFNAK contenant une adresse que l'homologue doit utiliser.

Il s'agit de la seule phase qui ne peut être correctement identifiée en examinant une seule ligne. Afin de vous assurer que le protocole IPCP (IP Control Protocol) s'active correctement, vous devez vérifier que les adresses IP ont été négociées dans les deux directions. Recherchez les lignes suivantes dans votre débogage :

*Mar  1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10

*Mar  1 00:06:36.971: BR0:1 IPCP:    Address 194.183.201.1(0x0306C2B7C901)

et

*Mar  1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10

*Mar  1 00:06:37.015: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)

et

*Mar  1 00:06:37.015: BR0:1 IPCP: State is Open

Ces trois ensembles de lignes ne se suivent pas immédiatement. Il est important de vérifier s'il existe un accusé de réception de la configuration sortante (O CONFACK) qui comporte, entre autres options, une adresse en dessous.

Il doit également y avoir une adresse IP entrante Configure Acknow (I CONFACK) avec une autre adresse IP en dessous.

Enfin, une ligne doit indiquer que l'état IPCP est ouvert. Après cela, vous devriez pouvoir envoyer une requête ping aux deux adresses IP directement à partir de votre routeur.

Revenir à l'organigramme du dépannage

Symptôme : La négociation PPP NCP (IPCP) n'aboutit pas

Problème : Échec de la négociation d'adresse IP

L’une des raisons pour lesquelles IPCP pourrait échouer est l’échec d’une négociation d’adresse IP. Par exemple, le serveur NAS peut tenter d'attribuer une adresse au client alors que le routeur client a une adresse IP différente configurée ou qu'un autre problème courant est lorsque le client demande une adresse et que le serveur NAS n'a aucune adresse disponible pour le client.

Sur le routeur appelant :

Si le routeur appelé attribue une adresse IP dynamiquement au routeur appelant, vérifiez que la commande ip address est négociée dans l'interface de numérotation.

Si le fournisseur/FAI NAS vous a donné une adresse IP statique, vérifiez que cette adresse IP (et ce masque de sous-réseau) est configurée dans l'interface de numérotation avec la commande ip address adresse_sous-réseau.

Sur le routeur appelé :

Assurez-vous que l'interface contrôlant la connexion (par exemple, int Dialer x) a une adresse IP et attribue une adresse à l'homologue à l'aide de la commande peer default ip address address.

Note: Si une adresse IP est configurée sur le routeur client, vous n'avez pas besoin d'attribuer une adresse à l'aide de la commande peer default ip address

Pour plus d'informations, reportez-vous au document Technologie commutée : Techniques de dépannage.

Problème : Le routeur appelé échoue à la liaison de profil de numéroteur

Si le nom d'utilisateur authentifié ne correspond pas au nom distant du numéroteur configuré sous l'interface de numérotation, l'appel sera déconnecté par le routeur appelé. Voici un exemple de sortie de numérotation de débogage pour une telle erreur :

Sur le routeur appelant :

Le débogage suivant montre une déconnexion causée par une liaison de profil de numérotation incorrecte sur le routeur appelé ;

*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"

*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"

*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"

*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4

! -- CHAP authentication is successful

*Mar 15 03:19:13.222: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0xA0

*Mar 15 03:19:13.226:         Cause i = 0x8090 - Normal call clearing

! -- We have received (RX) a DISCONNECT from the peer

! -- We have to move troubleshooting to the called router

*Mar 15 03:19:13.238: ISDN BR0: TX ->  RELEASE pd = 8  callref = 0x20

*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0

*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING

*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed

*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN

*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call

Note: Les débogages du côté appelé ne permettent pas de résoudre ce problème, sauf pour indiquer que l'homologue a déconnecté l'appel. Déplacez le dépannage vers le routeur appelé.

Sur le routeur appelé :

Le débogage suivant montre un échec d'appel en raison de problèmes de liaison de profil de numérotation :

*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4

*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33

*Mar 15 03:54:09.812: BR0:1 DDR:

Authenticated host maui-soho-03 with no matching dialer profile

! -- a binding failure because the dialer remote-name

! -- does not match the authenticated username

*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call

*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]

Solution :

Configurez la commande dialer pool number sur l'interface de numérotation. Le numéro de pool doit correspondre au numéro de pool configuré sur l'interface physique.

Configurez la commande dialer remote-name sur l'interface de numérotation. Le nom spécifié doit correspondre exactement au nom d'utilisateur fourni par le routeur distant pour l'authentification. Dans cet exemple, le nom d'utilisateur authentifié est maui-soho-03.

Pour plus d'informations de dépannage sur les problèmes de liaison, reportez-vous au document Configuration et dépannage des profils de numérotation.

Vous pouvez également utiliser la communauté d'assistance Cisco pour le dépannage PPP.

Revenir à l'organigramme du dépannage

Problèmes post-connexion

Symptôme : L'appel se déconnecte prématurément ou l'appel ne se déconnecte pas du tout

Si l'appel se déconnecte de manière inattendue ou si l'appel ne se déconnecte jamais, vérifiez le délai d'inactivité du numéroteur et la définition intéressante du trafic. Vous pouvez utiliser la commande debug dialer packet pour voir si un paquet particulier est intéressant ou non. Exemple :

Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes,

outgoing uninteresting (list 101)

Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes,

outgoing interesting (list 101)

Dans l'exemple ci-dessus, les paquets Hello OSPF ne sont pas intéressants par liste d'accès 101, tandis que le deuxième paquet est intéressant par liste d'accès 101.

1. Réglez le délai d'inactivité du numéroteur dans la configuration de l'interface de numérotation. La valeur par défaut est de 120 secondes, mais vous pouvez augmenter ou diminuer cette valeur selon vos besoins.

2. Modifiez la définition de trafic intéressante (configurée avec la commande dialer-list). Si l'appel se déconnecte prématurément, vous pouvez définir le trafic intéressant de manière plus souple. Si l'appel ne se déconnecte jamais, modifiez votre définition de trafic intéressante pour la rendre plus restrictive. Par exemple, vous pouvez définir le trafic de protocole de routage comme inintéressant. Voici un exemple de définition intéressante du trafic :
access-list 101 remark Interesting traffic for dialer-list 1

access-list 101 deny ospf any any

!--- mark OSPF as uninteresting

!--- This will prevent OSPF hellos from keeping the link up.

access-list 101 deny udp any any eq ntp

! -- Define ntp traffic as NOT interesting.

! -- This will prevent periodic ntp traffic from keeping

! -- the link up indefinitely.

access-list 101 permit ip any any

! -- All other IP traffic is interesting.

! -- Change this depending on your traffic needs.

dialer-list 1 protocol ip list 101

! -- this interesting traffic is applied to the dialer

! -- interface using dialer-group 1

Pour plus d'informations, reportez-vous au document Technologie commutée : Présentation et explications.

Symptôme : Le routeur compose régulièrement la connexion

Dans certaines situations, vous pouvez observer que le routeur compose régulièrement la connexion, même si aucun trafic utilisateur ne semble exiger que la liaison soit active. Cela peut entraîner des frais d'interurbain élevés lorsque le service RNIS est facturé à la minute.

La cause la plus courante est qu'un processus qui génère du trafic périodique (tel qu'un protocole de routage, ntp, snmp, etc.) peut être désigné par inadvertance comme intéressant. Le dépannage de ce problème se fait en deux étapes :

1. Identifiez le trafic qui entraîne la numérotation de la liaison.

2. Désignez ce trafic comme inintéressant.

Identifiez le trafic qui provoque la liaison à la numérotation.

Pour identifier le trafic qui entraîne la numérotation de la liaison, vous devez activer le paquet debug dialer. Surveillez le routeur lorsque la liaison RNIS est hors service et observez le trafic intéressant qui tente d’activer la liaison.

Astuce : À moins que cela ne soit nécessaire, indiquez que tous les protocoles de routage configurés sur le routeur ne sont pas intéressants.

L'exemple suivant montre que les HELLO OSPF périodiques sont marqués comme intéressants :

*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5),

64 bytes, outgoing interesting (ip PERMIT)

La seule façon d'identifier que le paquet ci-dessus est un paquet Hello OSPF provient de l'adresse de destination (d=224.0.0.5) définie pour OSPF. Le tableau suivant répertorie les adresses utilisées pour certains protocoles de routage courants :

Protocole de routage

Adresse de destination pour Périodique

Mises à jour ou mises à jour

RIPv1

255.255.255.255

RIPv2

224.0.0.9

EIGRP

224.0.0.10

OSPF

224.0.0.5

Le trafic entraînant la numérotation du routeur (protocole de routage ou tout autre trafic périodique) doit être marqué comme inintéressant.

Désigner le trafic périodique comme inintéressant

Modifiez la définition de trafic intéressante (configurée avec la commande dialer-list). Dans cet exemple, définissez le trafic OSPF et NTP comme non intéressant. Voici un exemple de définition intéressante du trafic :

access-list 101 remark Interesting traffic for dialer-list 1

access-list 101 deny ospf any any

!--- mark OSPF as uninteresting

!--- This will prevent OSPF hellos from keeping the link up.

access-list 101 deny udp any any eq ntp

! -- Define ntp traffic as NOT interesting.

! -- This will prevent periodic ntp traffic from keeping

! -- the link up indefinitely.

access-list 101 permit ip any any

! -- All other IP traffic is interesting.

! -- Change this depending on your traffic needs.

dialer-list 1 protocol ip list 101

! -- this interesting traffic is applied to the dialer interface

! -- using dialer-group 1

Pour plus d'informations, reportez-vous au document Technologie commutée : Présentation et explications.

Note: OSPF possède une fonctionnalité appelée circuit de demande qui peut également être utilisée ici. Référez-vous au document Pourquoi le circuit de demande OSPF continue à activer la liaison pour plus d'informations

Symptôme : Le deuxième canal B ne se connecte pas

Dans de nombreux cas, le routeur ne peut se connecter qu'à un canal B, tandis que l'autre canal B reste inactif. Pour plus d'informations sur le dépannage de ce problème, référez-vous au document Dépannage des pannes d'appel du deuxième canal B sur les liaisons RNIS BRI.

Problèmes de connectivité IP

Si la liaison RNIS apparaît mais que vous ne pouvez pas transmettre le trafic sur la liaison, le problème est probablement lié au routage ou à la NAT. Reportez-vous à la communauté d'assistance Cisco pour plus d'informations de dépannage.

Si vous utilisez la liaison RNIS comme sauvegarde d'une connexion WAN, reportez-vous au document Configuration et dépannage de la sauvegarde DDR.

Informations connexes

- Prise en charge de la technologie de routage à établissement de connexion à la demande (DDR)

- Support et documentation techniques - Cisco Systems