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

Organigramme du dépannage BRI RNIS

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


Introduction

Ce document vous aide à dépanner l'accès commuté d'accès de base (BRI) RNIS. Dans le résultat présenté d'organigramme et d'échantillon ci-dessous, nous avons installé une connexion RNIS BRI à l'autre utilisant des Profils de composeur. Cependant, les mêmes étapes de dépannage s'appliquent aux connexions à d'autres Routeurs (tels que des succursales) et en utilisant le Routage à établissement de connexion à la demande (DDR) existant.

Remarque: Vous pouvez également utiliser Cisco prenez en charge la Communauté afin de vous aider à résoudre votre problème RNIS.

Pour des informations d'introduction sur le RNIS et le DDR, référez-vous à la formation sonore située dans Cisco apprenant la connexion.

Organigramme

Cliquez sur en fonction un lien ci-dessous pour obtenir plus d'informations sur l'élément. Utilisez la touche back de votre navigateur pour retourner à cet organigramme.


Dépannage : Comment ouvrir une session et capturer ces debugs

Vous pouvez se connecter à votre routeur par le câble branché de console au port série de votre PC, ou à l'aide du telnet.

Si vous devez se connecter à votre routeur par la console, référez-vous s'il vous plaît à appliquer les paramétrages de l'émulateur de terminal corrects pour des connexions de console. Si votre routeur est déjà installé pour la Connectivité sur les Ethernets et vous voulez se connecter à votre routeur utilisant le telnet, utilisez simplement un client de telnet pour se connecter à l'adresse IP des Ethernets du routeur.

En tous cas (console ou telnet), il vaut mieux d'utiliser un client qui te permet pour garder un historique de la sortie reçue pendant la session, comme vous pouvez devoir faire défiler de retour dans votre sortie de débogage pour rechercher les messages particuliers.

Lancez les millisecondes sur la sortie de débogage et les messages de log. Une fois incité, entrez dans le mot de passe configuré sur votre routeur et écrivez le 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é utilisant le telnet, tapez le terminal monitor comme suit :

router#terminal monitor
router# 

Après ceci, sélectionnez les commandes de débogage 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#
Initiez alors le ping sur le routeur appelant. Est ci-dessous un exemple de sortie de débogage d'un appel réussi. Les différentes phases, comme identifiées dans l'organigramme, sont mises en valeur.
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#

De nouveau à l'organigramme de dépannage


Dépannage : Fait-elle la tentative de routeur de composer ?

Afin de découvrir si les tentatives de routeur de placer un appel, vérifient 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 la sortie de débogage, 8134 est le numéro de répertoire RNIS que le routeur tente de composer. Ce nombre a été spécifié utilisant la chaîne de numéroteur ou la commande de carte de numéroteur.

De nouveau à l'organigramme de dépannage


Symptôme : Le routeur ne tente pas de composer

Si votre routeur ne tente pas de composer, il y a plusieurs possibilités :

Aucune sortie de débogage du tout

S'il n'y a aucune sortie de débogage du tout, c'est le plus susceptible parce que le paquet IP que vous envoyez n'est pas même conduit à l'interface de numérotation. Les la plupart des causes classiques pour ceci sont :

  • Vérifiez que l'IP est configuré sur l'interface de numérotation. Vous devriez avoir un IP address sur l'interface de numérotation ou interface d'ip unnumbered (où l'interface est une interface up/up telle que les Ethernets X, le bouclage X etc.) ou ip address negotiated (si le client obtiendra une adresse IP du NAS). Si vous utilisez le DDR hérité, alors l'adresse IP devrait être configurée sur l'interface physique (exemple, interface bri 0).
  • Vérifiez que le Routage IP de commande est configuré. Quand vous regardez votre configuration utilisant la commande show running-config, vous ne devriez pas voir la commande aucun Routage IP.
  • Vérifiez qu'il y a une route statique pointant à l'interface de numérotation ou au prochain saut (si utilisant des Cartes de composeur).

    L'exemple suivant (pour le profil du numéroteur) est une artère statique pour 172.22.53.0/24 avec le prochain numéroteur 1 de saut :

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

    L'exemple suivant (pour le DDR hérité) est une artère statique pour 172.22.53.0/24 avec le prochain saut 172.16.1.1. L'adresse du prochain saut devrait apparier l'IP address dans l'instruction de mappage de numéroteur qui est utilisée pour le cadran :

    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 dedans administrativement vers le bas ou état de réserve. Utilisez l'interface dialer X d'exposition ou affichez la commande de l'interface bri X de s'assurer que l'interface est dans l'état up/up (mystification).

    Si l'interface est administrativement en baisse, alors n'utilisez l'aucune commande shutdown dans le mode de configuration d'interface.

    Si l'interface est dans l'état de réserve, alors le numéroteur ou l'interface BRI est une sauvegarde à une connexion qui est en hausse. Vous pouvez enlever la commande backup interface sous l'interface principale ou tirer le câble de l'interface principale.

Il y a sortie de débogage mais aucun « tenter pour composer » le message

Dans ce cas, il y a probablement un paquet IP conduit à l'interface, mais le routeur la jette et n'initie pas l'appel pour quelque raison. Regardez la sortie de débogage afin de découvrir pourquoi la tentative d'appel n'est pas faite. Sont ci-dessous quelques exemples de sortie de débogage et leurs possibles raison :

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é n'apparie pas la définition du trafic intéressant. Pour cet exemple, modifiez la liste d'accès 101.

Un defintion simple du trafic intéressant serait de permettre tout le trafic IP comme dans :

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

Avertissement : Le repérage de tout le trafic IP en tant qu'intéressant peut faire rester la liaison RNIS indéfiniment, particulièrement si vous avez un protocole de routage ou tout autre trafic périodique. Ajustez la définition du trafic intéressant pour adapter à vos besoins.

Pour plus d'informations sur le trafic intéressant, référez-vous au document Technologie d'appel commuté : Aperçus 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).

Il n'y a aucun dialer-group configuré sur l'interface de numérotation. Ajoutez un dialer-group comme dans l'exemple suivant :

 interface Dialer1
  dialer-group X

Remarque: La valeur pour X devrait être la même utilisée avec la commande de 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 y a une déclaration de dialer-group sur l'interface de numérotation, mais le dialer-list visé n'existe pas. Configurez le dialer-list comme dans l'exemple suivant :

dialer-list X protocol ip permit

Remarque: La valeur pour X devrait être la même utilisée avec l'ordre de 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é assez intéressant pour évoquer le lien, mais il n'y a aucune interface physique disponible pour placer l'appel. Assurez-vous que le pool-member de numéroteur X est configuré dans l'interface physique et le groupe de numérotation X est configuré dans l'interface de numérotation. Exemple :

interface BRI0
 dialer pool-member 1
!
interface Dialer1
 dialer pool 1

En outre, vérifiez que l'interface BRI n'est pas dans l'é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éroteur n'est configurée sur l'interface de numérotation. Le routeur veut placer un appel mais ne connaît pas le nombre de répertoire RNIS pour appeler. Définissez une numéroteur-chaîne :

interface Dialer1
 dialer string 8134

Pour plus d'information de dépannage, référez-vous à la section « que le routeur appelant n'envoie pas un message de configuration » dans le document dépannant la couche 3 RNIS BRI utilisant la commande de debug isdn q931.

De nouveau à l'organigramme de dépannage


Dépannage : L'appel RNIS se connecte-t-il avec succès ?

Afin d'identifier si l'appel RNIS se connecte, recherchez un message CONNECT_ACK et %LINK-3-UPDOWN dans met au point :
*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 vous voyez ce message, votre appel RNIS connecté avec succès et vous pouvez poursuivre à l'étape suivante. Si vous ne voyez pas un message comme ceci, lisez ci-dessous pour des causes possibles.

De nouveau à l'organigramme de dépannage


Symptôme : L'appel RNIS ne se connecte pas avec succès

  1. Si vous voyez la sortie semblable au suivant, vérifiez que le câble RNIS est branché le routeur et la prise de l'opérateur de téléphonie.
    *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 d'état de show isdn de vérifier cette couche 1 est EN ACTIVITÉ, la couche 2 est MULTIPLE_FRAME_ESTABLISHED et les SPID (si nécessaire) sont valides. Le pour en savoir plus se rapportent au document utilisant la commande d'état de show isdn pour le dépannage BRI.

    Si vous avez la sortie d'une commande d'état de show isdn de votre périphérique de Cisco, vous pouvez utiliser pour afficher des éventuels problèmes et des difficultés. Pour utiliser , vous devez être un utilisateur enregistré, être ouvert une session, et faire activer le Javascript.
  3. Vérifiez que la chaîne configurée de numéroteur RNIS est correcte. Maintenez dans l'esprit que vous pouvez devoir ajouter de principaux zéro, neuf ou autres chiffres pour obtenir un fil extérieur quand vous êtes connecté par un PBX.

  4. Si la connexion emploie un contact d'opérateur interurbain votre compagnie de téléphone et fournisseur de services interurbains locaux pour vérifier que le service est lancé. Souvent, la compagnie de téléphone locale a le circuit RNIS misconfigured tels que des appels longue distance sortants RNIS ne sont pas orientés vers le réseau du fournisseur de services interurbains approprié. Vous devriez également vérifier que le réseau de fournisseurs de services interurbains fonctionne.

    Aux États-Unis, et dans les situations où la compagnie de téléphone ou le fournisseur de services interurbains ne peut pas rectifier le problème, vous pouvez souhaiter utiliser un pré-abonnement auprès d'un opérateur interurbain (PIC). Les codes PIC sont des préfixes de sept-chiffre qui identifient des opérateurs interurbains des États-Unis aux entreprises de téléphonie locale (LEC). Ceci permet à des clients pour utiliser différents opérateurs interurbains pour différents appels. Le code PIC est configuré comme un préfixe au numéro composé. La plupart de PICS sont du format 1010xxx.

    N'employez aucune carte de numéroteur de chaîne xxxxx ou aucun de numéroteur pour retirer le nombre existant et puis pour configurer le nouveau nombre.

    Par exemple, chaîne 10103215125551111 de numéroteur.

  5. Recherchez un message de déconnexion RNIS.

    Le logiciel de Cisco IOS® décode le cause-code dans ce message de débranchement et te donne un message texte clair qui contient souvent les informations utiles menant à la cause du problème. Les chaînes possibles que vous pouvez trouver ici incluent :

    • Numéro non alloué ou non affecté
    • Destination incompatible (qui indiquent que le numéro composé pourrait être incorrect)
    • Nombre occupé (qui indique que le côté appelé est occupé)
    • Défaillance provisoire (qui indique une panne provisoire sur le réseau de l'opérateur de téléphonie)

  6. Afin de trouver le possible raison pour une cause spécifique de débranchement, référez-vous s'il vous plaît compréhension derrière codes de motif de déconnexion de debug isdn q931.

    Par exemple, un débranchement dû à un isdn number incorrect peut être indiqué avec :

    *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 de codes de motif de déconnexion référencé précédemment, nous pouvons déterminer que le code de débranchement a été provoqué par par une tentative de se connecter à un matériel le non-RNIS (par exemple, une ligne analogique).

    Un débranchement dû incorrectement à un nombre formaté peut être indiqué 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 derrière codes de motif de déconnexion de debug isdn q931 de document compréhension, nous pouvons déterminer que le code de débranchement a été provoqué par par un format non valide pour le numéro RNIS distant. La connexion échoue parce que l'adresse de destination est présentée (au commutateur) dans un format non identifiable, ou l'adresse de destination est inachevée.

    L'exemple suivant affiche un appel rejeté dû à un isdn number 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

  7. Si votre compagnie de téléphone t'a fournie les identifiants de service profile (SPID) à utiliser, assurez-vous que ces SPID sont configurés sur l'interface BRI. Les SPID sont utilisés généralement seulement aux États-Unis et avec des switchtypes Ni et de SGD (les switchtypes 5ess n'ont pas besoin de SPID).
    interface BRI0
     isdn spid1 51255511110101 5551111
     isdn spid2 51255511120101 5551112
  8. Vous pouvez utiliser la commande d'état de show isdn de vérifier si les SPID sont corrects.

    Le pour en savoir plus, se rapportent au document dépannant le RNIS BRI SPID.

    Si vous avez la sortie d'une commande d'état de show isdn de votre périphérique de Cisco, vous pouvez utiliser pour afficher des éventuels problèmes et des difficultés. Pour utiliser , vous devez être un utilisateur enregistré, être ouvert une session, et faire activer le Javascript.

  9. Si la procédure ci-dessus n'a pas résolu le problème, utilisez le document dépannant la couche 3 RNIS BRI utilisant la commande de debug isdn q931 pour davantage de dépannage.

De nouveau à l'organigramme de dépannage


Dépannage : La phase du PPP LCP réussit-elle ?

Dans la sortie de débogage, vous devriez voir une ligne de message à ce qui suit :
*Mar  1 00:06:36.887: BR0:1 LCP: State is Open
Si vous voyez cette ligne, ceci indique que le Link Control Protocol (LCP) a été négocié avec succès. N'importe quel état autre qu'ouvert indique que LCP a manqué.

De nouveau à l'organigramme de dépannage


Symptôme : La phase du PPP LCP ne réussit pas

Cause possible : Le PPP n'est pas configuré

Si vous avez la sortie de débogage semblable aux lignes suivantes, ceci indique que le PPP n'a pas commencé.

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

Note de la sortie de débogage que le routeur n'envoie aucun message du PPP CONFREQ. C'est probablement parce que l'interface n'a pas été configurée pour l'encapsulation PPP.

Dans ce cas, vérifiez que vous avez configuré la commande d'encapsulation ppp sous l'interface de numérotation et l'interface physique. Ce qui suit sont des exemples :

interface Dialer1
 encapsulation ppp


or
interface BRI 0
encapsulation ppp

Cause possible : Non-concordance de vitesse RNIS

Parfois vous pouvez ne voir seulement les messages sortants LCP CONFREQ, mais aucun message d'arrivée LCP. Un exemple est affiché ci-dessous :

*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 pourrait sont provoqué par par :
  • L'extrémité distante n'étant pas configuré pour le PPP. Configurez l'encapsulation ppp de commande sur l'extrémité distante
  • Paquets n'obtenant pas par les supports de transmission. La plupart de cause classique pour ceci est une non-concordance de vitesse RNIS

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

Pour des Profils de composeur :

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 le legs DDR (Cartes de composeur) :

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 n'acceptent pas sur une authentification Protocol (CHAP ou PAP) de les utiliser

Si vous avez la sortie de débogage semblable aux lignes suivantes, ceci indique que votre routeur et le côté distant n'ont pas accepté sur un protocole d'authentification de les 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é ce qui suit :

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 d'authentification CHAP (Challenge Handshake Authentication Protocol) ou le Password Authentication Protocol (PAP), référez-vous aux documents suivants :

Vous pouvez également utiliser Cisco prenez en charge la Communauté pour davantage de dépannage de PPP.

De nouveau à l'organigramme de dépannage


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

Vérifiez la sortie de débogage pour une ligne semblable à ceci :
*Mar  1 00:06:36.943: BR0:1 PPP: Phase is UP

De nouveau à l'organigramme de dépannage


Symptôme : L'authentification de PPP ne réussit pas

Assurez-vous 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, est votre nom d'utilisateur et YYYYY est votre mot de passe.

Remarque: Configurez seulement le nom d'utilisateur et mot de passe pour la méthode d'authentification vous et votre pair utilisent. Par exemple, si vous chacun des deux n'utiliserez pas le PAP, puis vous n'avez pas besoin de la commande de ppp pap sent-username. Cependant, si vous êtes incertain si le support PAP de pair ou CHAP, alors configurez chacun des deux.

Selon votre Cisco IOS version de logiciel et configuration, le mot de passe peut révéler chiffré dans votre configuration. Si c'est le cas, en faire une commande de show running-configuration, vous voient le mot « mot de passe » suivi du chiffre 7 et puis d'un ordre des nombres, comme dans l'exemple suivant :

interface Dialer1
 ppp chap password 7 140005

Dans ce cas, vous ne pouvez pas vérifier, que le mot de passe configuré soit correct ou pas en regardant la configuration. Pour être sûr que le mot de passe est correct, écrivez simplement le mode de configuration et retirez et configurez le mot de passe de nouveau. Pour identifier une panne de mot de passe dans le débogage, comparez votre sortie de débogage à la sortie témoin ci-dessous.

Si ce routeur authentifiera le pair, alors soyez sûr de configurer le password password de nom d'utilisateur nom d'utilisateur de commande, où le nom d'utilisateur est le nom fourni par le routeur de pair pour l'authentification.

Exemple 1

Un message comme celui signifie ci-dessous que le mot de passe CHAP est non 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

Conseil : Une panne entrante de CHAP (indiquée par le CHAP : I LA PANNE) signifie que le pair ne pouvait pas authentifier le routeur. Employez le debug ppp negotiation sur le routeur de pair pour déterminer la cause précise de la panne.

Le pour en savoir plus se rapportent à l'authentification de PPP de document utilisant les commandes de callin de CHAP d'authentification de ppp chap hostname et de ppp.

Exemple 2

Un message comme celui ci-dessous pourrait signifier que le nom d'utilisateur de CHAP est non 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

Conseil : Une panne entrante de CHAP (indiquée par le CHAP : I LA PANNE) signifie que le pair ne pouvait pas authentifier le routeur. Employez le debug ppp negotiation sur le routeur de pair pour déterminer la cause précise de la panne.

Le pour en savoir plus, se rapportent à l'authentification de PPP de document utilisant les commandes de callin de CHAP d'authentification de ppp chap hostname et de ppp.

Exemple 3

Un message comme ci-dessous signifie que le mot de passe PAP est non 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
Le pour en savoir plus se rapportent au document configurant et dépannage du Password Authentication Protocol (PAP) de PPP.

Exemple 4

Un message comme ci-dessous signifie que le nom d'utilisateur PAP est non 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

Le pour en savoir plus se rapportent au document configurant et dépannage du Password Authentication Protocol (PAP) de PPP.

Vous pouvez également utiliser Cisco prenez en charge la Communauté pour davantage de dépannage de PPP.

De nouveau à l'organigramme de dépannage


Dépannage : La phase du NCP de PPP (IPCP) se termine-elle ?

L'élément principal négocié dans IPCP est l'adresse de chaque pair. Avant négociation IPCP, chaque pair est dans un de deux états possibles ; ou il a une adresse IP ou il ne fait pas. Si le pair a déjà une adresse, elle envoie cette adresse dans un CONFREQ à l'autre pair. Si l'adresse semble acceptable à l'autre pair, un CONFACKis est retourné. Si l'adresse n'est pas acceptable, la réponse est un CONFNAK contenant une adresse pour que le pair l'utilise.

C'est la seule phase qui ne peut pas être correctement identifiée en regardant juste une ligne. Dans la commande à être sûre que le protocole de contrôle IP (IPCP) monte correctement, vous devez vérifier que des adresses IP ont été négociées dans les deux directions. Le regardez votre mettent au point pour les lignes suivantes :

*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 peuvent immédiatement ne pas se suivre. Il est important que vous vérifiiez s'il y a un sortant configurent reconnaissent (O CONFACK) qui a, entre d'autres options, une adresse sous lui.

Il doit également y avoir un entrant configurent reconnaissent (I CONFACK) avec une autre adresse IP sous elle.

En conclusion, il doit y a une ligne déclarant que l'état IPCP est ouvert. Après ceci, vous devriez être tellement avec succès ping capable les deux adresses IP directement de votre routeur.

De nouveau à l'organigramme de dépannage


Symptôme : La négociation du NCP de PPP (IPCP) ne réussit pas

Problème : La négociation d'adresse IP échoue

Un de la raison pour laquelle IPCP pourrait échouer est dû à une panne de négociation d'adresse IP. Par exemple, le NAS peut essayer d'assigner une adresse au client tandis que le routeur client fait configurer une adresse IP différente ou un autre problème courant est quand le client demande une adresse et le NAS n'a aucune adresse disponible pour le client.

Sur le routeur appelant :

Si le routeur appelé assigne une adresse IP dynamiquement au routeur appelant, vérifiez que vous avez l'ip address negotiated de commande dans l'interface de numérotation.

Si le NAS Provider/ISP t'a donné une adresse IP statique, vérifiez que cet IP address (et masque de sous-réseau) est configuré dans l'interface de numérotation avec le subnet_mask d'adresse d'IP address de commande.

Sur Router appelé :

Assurez l'interface contrôlant la connexion (par exemple, le numéroteur international x) a une adresse IP et assigne une adresse au pair utilisant la commande d'adresse de peer default ip address.

Remarque: Si le routeur client a une adresse IP vous a configuré alors n'a pas besoin d'assigner une adresse utilisant la commande de peer default ip address

Le pour en savoir plus se rapportent au document Technologie d'appel commuté : Techniques de dépannage.

Problème : Le routeur appelé échoue attache de profil du numéroteur

Si le nom d'utilisateur authentifié n'apparie pas le dialer remote-name configuré sous l'interface de numérotation, alors l'appel sera déconnecté par le routeur appelé. Ce qui suit est un échantillon met au point le numéroteur sorti pour une telle erreur :

Sur le routeur appelant :

Ce qui suit met au point des expositions qu'un débranchement a entraînées par un mauvais profil du numéroteur liant 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

Remarque: Met au point du côté appelé n'aident pas en dépannant ce problème excepté pour indiquer que le pair a déconnecté l'appel. Déplacez le dépannage au routeur appelé.

Sur Router appelé :

Ce qui suit met au point des expositions manquer d'appel dû aux questions obligatoires de profil du numéroteur :

*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 de numéro du pool de routeurs d'appels sur l'interface de numérotation. Le nombre de groupe doit apparier le nombre de groupe configuré sur l'interface physique.

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

Pour davantage information de dépannage sur les questions obligatoires référez-vous au document configurant et dépannage des Profils de composeur.

Vous pouvez également utiliser Cisco prenez en charge la Communauté pour davantage de dépannage de PPP.

De nouveau à l'organigramme de dépannage


Problèmes de POST-connexion

Symptôme : Les débranchements d'appel pr3maturément ou l'appel ne déconnecte pas du tout

Si les débranchements d'appel inopinément ou d'appel les débranchements jamais, vérifient le defintion de dialer idle-timeout et de trafic intéressant. Vous pouvez utiliser la commande de paquet de numéroteur de débogage de voir si un paquet particulier est intéressant ou pas. 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 hellos OSPF sont inintéressants par liste d'accès 101, alors que le deuxième paquet est intéressant par liste d'accès 101.
  1. Ajustez le dialer idle-timeout en configuration de l'interface du numéroteur. Le par défaut est de 120 secondes, mais vous pouvez souhaiter soulever ou diminuer cette valeur selon vos besoins.

  2. Changez la définition du trafic intéressant (configurée avec la commande de dialer-list). Si les débranchements d'appel pr3maturément que vous pouvez souhaiter pour définir le trafic intéressant plus lâchement. Si les débranchements d'appel ne changent jamais votre définition du trafic intéressant pour être plus restrictifs. Par exemple, vous pouvez définir le trafic de protocole de routage comme inintéressant. Voici une définition du trafic intéressant d'échantillon :
    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

    Le pour en savoir plus se rapportent au document Technologie d'appel commuté : Aperçus et explications.

Symptôme : Le routeur compose périodiquement la connexion

Dans certaines situations, vous pouvez observer que le routeur compose périodiquement la connexion, quoiqu'il n'y ait aucun trafic apparent d'utilisateur exigeant du lien d'être. Ceci peut avoir comme conséquence les taxations élevées où le service RNIS est facturé sur une base de par-minute.

La plupart de cause classique est qu'un processus qui génère le trafic périodique (tel qu'un protocole de routage, ntp, SNMP etc.) peut être par distraction indiqué en tant qu'intéressant. Le dépannage de ceci est une question en deux étapes :

  1. Identifiez le trafic qui fait composer le lien.
  2. Indiquez ce trafic comme inintéressant.

Identifiez le trafic qui fait composer le lien.

Pour identifier le trafic qui fait composer le lien, vous devez activer mettez au point le paquet de numéroteur. Surveillez le routeur tandis que la liaison RNIS est en baisse et l'observez pour du trafic intéressant périodique qui tente d'évoquer le lien.

Conseil : À moins que spécifiquement nécessaire, indiquez tous les protocoles de routage configurés sur le routeur comme inintéressant.

L'exemple suivant affiche des hellos périodiques OSPF étant marqués en tant qu'intéressant :

*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 manière de identifier que le paquet ci-dessus est un OSPF bonjour est de l'adresse de destination (d=224.0.0.5) qui est définie pour l'OSPF. Le tableau suivant présente les adresses utilisées pour quelques protocoles de routage communs :

Protocole de routage
Adresse de destination pour périodique
Mises à jour ou Keepalives
RIPv1
255.255.255.255
RIPv2
224.0.0.9
EIGRP
224.0.0.10
OSPF
224.0.0.5

Le trafic faisant composer le routeur (procol de routage ou tout autre trafic périodique) devrait être marqué en tant qu'inintéressant.

Indiquez le trafic périodique comme inintéressant

Changez la définition du trafic intéressant (configurée avec la commande de dialer-list). Dans cet exemple, définissez le trafic OSPF et de NTP comme inintéressant. Voici une définition du trafic intéressant d'échantillon :

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

Le pour en savoir plus se rapportent au document Technologie d'appel commuté : Aperçus et explications.

Remarque: L'OSPF a une caractéristique appelée l'exigence-circuit qui peut également être utilisé ici. Référez-vous au document pourquoi l'OSPF Demand Circuit continue à apporter le pour en savoir plus de lien

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

Dans de nombreux cas, le routeur peut seulement se connecter sur un canal B, alors que les autres séjours de canal B tournent au ralenti. Pour plus d'informations sur dépanner cette question référez-vous échecs d'appel de canal B de dépannage de document aux deuxièmes sur des liens RNIS BRI.

Questions de connectivité IP

Si la liaison RNIS est soulevée mais vous ne pouvez pas passer le trafic à travers le lien alors que la question est probablement un routage ou un problème relatif NAT. Référez-vous à la Communauté de support de Cisco pour plus d'information de dépannage.

Si vous utilisez la liaison RNIS comme sauvegarde à une connexion WAN, alors référez-vous au document configurant et dépannant la sauvegarde DDR.

Conversations connexes de la communauté de soutien de Cisco

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


Informations connexes


Document ID: 20602