Organigramme du dépannage BRI RNIS
Contenu
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
- 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)
- 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é. - 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.
- 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.
- 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
- 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é. - 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.
- 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.
- 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 1Pour 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 :
- Identifiez le trafic qui entraîne la numérotation de la liaison.
- 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
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)