Dépannage des échecs d'appel du second canal B sur les liaisons BRI RNIS

Options de téléchargement

  • PDF     (226.2 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (108.7 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (197.7 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:17 octobre 2005
ID du document:22480

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Le protocole MPPP (Multilink Point-to-Point Protocol) vous permet de regrouper les deux canaux B dans une connexion RNIS BRI. Le protocole MPPP fournit 128 k (2 x 64 kbits/s) de bande passante entre les périphériques finaux RNIS. Cependant, dans de nombreux cas, les routeurs ne peuvent se connecter qu'à un canal B, tandis que l'autre canal B reste inactif. Ce document explique comment résoudre des problèmes dans de telles situations.

Remarque : Cette procédure concerne principalement la connexion à une liaison BRI (c'est-à-dire deux canaux B). Si vous utilisez MPPP pour regrouper deux ou plusieurs BRI (c'est-à-dire au moins trois canaux B), référez-vous à Configuration du protocole PPP multiliaison avec plusieurs interfaces BRI.

Conditions préalables

Conditions requises

Vérifiez si les routeurs peuvent se connecter entre eux avec un canal B. Ce document ne couvre que les échecs de connexion liés au canal multiliaison supplémentaire. Si vous ne parvenez pas à vous connecter à un canal, reportez-vous à l'organigramme de dépannage RNIS BRI.

Ne poursuivez pas la procédure de ce document à moins que le premier canal ne se connecte correctement.

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Concepts généraux de configuration RNIS et de routage à établissement de connexion à la demande (DDR). Reportez-vous à la présentation de formation pour obtenir des informations supplémentaires sur la configuration de base RNIS et DDR disponible sur Cisco Learning Connection.

  • Comment déboguer RNIS et PPP. Vous devez être en mesure de déterminer si le routeur compose des numéros, se connecte au niveau de la couche RNIS et négocie le protocole PPP.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Logiciel Cisco IOS® versions 12.1(2) et 12.2(2)T

    Cisco a introduit la commande dialer redial dans le logiciel Cisco IOS® Version 12.1(2). Plus tard, Cisco a modifié la commande pour inclure des options supplémentaires dans le logiciel Cisco IOS Version 12.2(2)T. Pour plus d'informations sur cette fonctionnalité, référez-vous à Rappeler les améliorations.

  • Deux routeurs connectés à des circuits BRI actifs.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Description du problème

Un routeur active les deux canaux B sur l’accès de base pour tenter de se connecter à l’homologue RNIS. La connexion à l'homologue réussit. Cependant, un seul canal B se connecte correctement. Multilink PPP tente d’activer le canal B supplémentaire, mais l’appel échoue continuellement.

Ce diagramme illustre le flux d'appels pour un appel réussi :

ppp_multilink_ts2.gif

Questions que vous devez poser à l'opérateur téléphonique

Lorsque vous configurez et dépannez la multiliaison, posez les questions suivantes à l'opérateur téléphonique du routeur APPELÉ :

  1. Question : Faut-il composer un ou deux numéros pour se connecter aux deux canaux B distants ?

    Réponse :

    Un numéro : Configurez une chaîne de numérotation ou une carte de numérotation unique sur l'interface physique ou de numérotation du routeur local, selon le cas. Reportez-vous à l'étape 4 pour plus d'informations. Passez à la question 2.

    Deux numéros : Sur le routeur local, configurez une carte de numérotation ou une chaîne de numérotation pour chaque numéro RNIS B-channel distant. Reportez-vous à l'étape 4 pour plus d'informations.

  2. Question : Les deux numéros de canal B sont-ils configurés dans un groupe de recherche ?

    Réponse :

    Oui: Il s'agit du paramètre attendu pour les circuits qui n'ont besoin que d'un numéro pour se connecter aux deux canaux B. Le groupe de recherche lie les deux numéros de canal B (le côté APPELANT n'a besoin que d'un seul numéro pour appeler). Une fois le premier canal B connecté, le routeur APPELANT compose à nouveau le même numéro. Le commutateur à l’extrémité distante, le plus proche du routeur APPELÉ, reconnaît que le premier canal B est occupé et transfère l’appel sur le second canal B, ce qui rend possible le regroupement.

    Non: Demandez à l'opérateur téléphonique de configurer les deux numéros de canaux B dans un groupe de recherche et de renvoyer automatiquement un appel vers le deuxième numéro lorsque le premier est occupé. Si la compagnie de téléphone ne configure pas le groupe de recherche, configurez la commande dialer redial ou isdn fast-rollver delay comme expliqué à l'étape 5 de la section Dépannage.

Dépannage

Remarque : Avant d'utiliser cette procédure, vérifiez si les routeurs sont connectés entre eux à l'aide d'un canal B. Si vous ne parvenez pas à vous connecter à un canal, reportez-vous à l'organigramme de dépannage RNIS BRI.

  1. Activez les commandes de débogage suivantes : debug dialer, debug isdn q931 et debug ppp negotiation.

  2. Lancez le trafic destiné au périphérique distant. Assurez-vous que le trafic est suffisant pour initier l'appel supplémentaire.

    Conseil : Vous pouvez utiliser l'utilitaire ping étendu pour modifier la taille du datagramme/paquet et le nombre de requêtes ping. Référez-vous à Utilisation des commandes Extended ping et Extended traceroute pour plus d'informations sur l'utilisation des requêtes ping étendues.

  3. Vérifiez si le routeur tente le deuxième appel. Les débogages apparaissent comme ceci :

    *Mar  1 01:30:55.295: BRI3/0 DDR: rotor dialout [priority]

!--- Use BRI 3/0 to dial out.

*Mar  1 01:30:55.295: BRI3/0 DDR: Dialing cause ip 
(s=10.1.1.1, d=172.22.53.201)

!--- DDR dialing cause is a ping to the remote router.

*Mar  1 01:30:55.295: BRI3/0 DDR: Attempting to dial 5558888

!--- Dial the remote number.

*Mar  1 01:30:55.295: ISDN BR3/0: TX ->  SETUP pd = 8  callref = 0x07
*Mar  1 01:30:55.299:         Bearer Capability i = 0x8890218F
*Mar  1 01:30:55.299:         Channel ID i = 0x83
*Mar  1 01:30:55.299:         Keypad Facility i = '5558888'

  4. Le routeur tente-t-il le deuxième appel ?

    • Oui: Passez à l'étape 5.

    • Non: Cela signifie que le routeur n’est pas correctement configuré pour le protocole PPP multiliaison. Configurez ces commandes :

      Commande Description
      ppp multilink Configurez la commande ppp multilink (sur les deux routeurs) sous l'interface physique et l'interface de numérotation (si vous utilisez des profils de numérotation).

      Remarque : si vous ajoutez cette commande, vous devez déconnecter les connexions existantes, puis vous reconnecter pour les nouveaux paramètres multiliaison que vous voulez appliquer. La négociation multiliaison se produit lors de la configuration de l'appel. Par conséquent, les modifications apportées à la multiliaison ne sont pas implémentées sur les connexions ayant terminé la négociation LCP.
      dialer load-threshold 5 outbound Charge d’interface (de 1 à 255) au-delà de laquelle le numéroteur lance un autre appel vers la destination. La bande passante est un ratio de 255, où 255 représente 100 % de la bande passante disponible. Dans cet exemple, le canal supplémentaire apparaît lorsque la charge sortante sur la liaison est de 5/255 ou 2 %. Variez cette valeur en fonction de vos besoins.

      Conseil : Les utilisateurs configurent parfois la commande dialer load-threshold 1 pour utiliser tous les canaux B immédiatement pour chaque appel. La théorie sous-jacente à cette configuration est que si tous les canaux B sont activés en même temps et que chaque appel utilise l’ensemble du canal RNIS, l’appel doit être plus court, car les données utilisateur ont besoin de moins de temps pour le transfert.

      Bien que cette théorie soit valable, en pratique, Cisco recommande de ne jamais définir de valeur de seuil de charge de numéroteur inférieure à 3. Si vous définissez cette valeur sur moins de 3, plusieurs canaux RNIS s'activent simultanément, ce qui entraîne des conflits entre les deux canaux et un échec de connexion avec l'un d'eux.
      dialer map ip address name name number or dialer string number Configurez une carte de numérotation (ou chaîne de numérotation) pour chaque numéro RNIS B-channel distant. L'adresse IP et le nom des deux instructions doivent être identiques, seul le numéro RNIS doit être différent. Exemple : 
      dialer map ip 192.168.1.1 name asc001 13305551111
dialer map ip 192.168.1.1 name asc001 13305551112
      ou 
      dialer string 13305551111
dialer string 13305551112

      Remarque : si le service téléphonique vous informe que vous n'avez besoin que d'un numéro, vous n'avez besoin que d'une seule instruction dialer map ou dialer string.

      Pour plus d'informations sur les options de configuration du protocole PPP multiliaison, référez-vous à Multilink PPP pour DDR - Configuration et vérification de base.

  5. Configurez l'une de ces commandes sous l'interface physique ou de numérotation :

    • intervalle de rappel 5 tentatives 3 - L'intervalle entre les tentatives de numérotation est de cinq secondes, pour un maximum de trois tentatives.

      Cet intervalle permet de décomposer complètement l'ancien appel avant la tentative de rappel.

    • isdn fast-rollover-delay 5 - Définissez le délai de transfert sur 5 secondes.

      Fournissez ce délai pour permettre le démontage complet de l'ancien appel avant la nouvelle tentative d'appel. Cette commande est nécessaire sur certains commutateurs RNIS, car la nouvelle tentative d'appel peut se produire avant que l'ancien appel ne soit complètement désactivé. Cela entraîne l'échec du deuxième appel.

Exemple de sortie

Cette section fournit un exemple de configuration et de résultat de débogage pour un appel réussi ou non. Utilisez cette section comme référence pour vérifier si les débogages que vous observez correspondent à ceux affichés ici :

ppp_multilink_ts1.gif 

interface BRI1/0
 ip address 192.168.1.111 255.255.255.0
 encapsulation ppp
 dialer map ip 192.168.1.1 name asc001 13305551111
 dialer map ip 192.168.1.1 name asc001 13305551112
 
!--- Notice that the dialer map statements are identical except for !--- the phone numbers to dial. !--- The numbers correspond to the ISDN numbers of the remote BRI. !--- This router will use the first dialer map, then the second dialer map. 

 dialer load-threshold 1 either

 !--- Set the load-threshold to the required value and direction dialer-group 1.

 isdn switch-type basic-ni
 isdn spid1 25255588880101 5558888
 isdn spid2 25255588890101 5558889 
 isdn fast-rollover-delay 5
 

 !--- Rollover delay is set to 5 seconds.

 ppp authentication chap pap callin
 ppp multilink

 !--- Enable multilink on the interface.

Activez debug isdn q931 et debug ppp negotiation et lancez une requête ping à l'adresse IP distante. 

asc011#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Aug 24 16:30:35.651 est: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x3B
Aug 24 16:30:35.655 EST: Bearer Capability i = 0x8890218F
Aug 24 16:30:35.655 EST: Channel ID i = 0x83
Aug 24 16:30:35.659 EST: Keypad Facility i = '13305551111' 

!--- Calling out with the number specified in the first dialer map.

Aug 24 16:30:35.896 EST: ISDN BR1/0: RX <- CALL_PROC pd = 8 callref = 0xBB
Aug 24 16:30:35.896 EST: Channel ID i = 0x89
Aug 24 16:30:35.900 EST: Locking Shift to Codeset 5
Aug 24 16:30:35.900 EST: Codeset 5 IE 0x2A i = 0x80880B,'13305551111', 
  0x800109800114800114800114..
Aug 24 16:30:38.877 EST: ISDN BR1/0: RX <- ALERTING pd = 8 callref = 0xBB
Aug 24 16:30:38.881 EST: Signal i = 0x01 - Ring back tone on
Aug 24 16:30:38.929 EST: ISDN BR1/0: RX <- CONNECT pd = 8 callref =0xBB
Aug 24 16:30:38.929 EST: Signal i = 0x3F - Tones off
Aug 24 16:30:38.937 EST: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to up
Aug 24 16:30:38.941 EST: BR1/0:1 PPP: Treating connection as a callout
Aug 24 16:30:38.945 EST: BR1/0:1 PPP: Phase is ESTABLISHING, Active Open
  [0 sess , 0 load]
Aug 24 16:30:38.945 EST: BR1/0:1 PPP: No remote authentication for call-out
Aug 24 16:30:38.945 EST: BR1/0:1 LCP: O CONFREQ [Closed] id 5 len 23
Aug 24 16:30:38.945 EST: BR1/0:1 LCP: MagicNumber 0x55EE5FC7 (0x050655EE5FC7)
Aug 24 16:30:38.945 EST: BR1/0:1 LCP: MRRU 1524 (0x110405F4)
Aug 24 16:30:38.949 EST: BR1/0:1 LCP: EndpointDisc 1 Local 
  (0x130901617363303131)
Aug 24 16:30:38.949 EST: ISDN BR1/0: TX -> CONNECT_ACK pd = 8 callref = 0x3B
...

!--- Output omitted.

...
Aug 24 16:30:39.009 EST: BR1/0:1 LCP: I CONFACK [ACKsent] id 5 Len 23
Aug 24 16:30:39.009 EST: BR1/0:1 LCP: MagicNumber 0x55EE5FC7(0x050655EE5FC7)
Aug 24 16:30:39.009 EST: BR1/0:1 LCP: MRRU 1524 (0x110405F4)
Aug 24 16:30:39.009 EST: BR1/0:1 LCP: EndpointDisc 1 Local 
  (0x130901617363303131)
Aug 24 16:30:39.013 EST: BR1/0:1 LCP: State is Open
Aug 24 16:30:39.013 EST: BR1/0:1 PPP:Phase is AUTHENTICATING, by the peer
  [0 sess, 0 load]
Aug 24 16:30:39.057 EST: BR1/0:1 CHAP: I CHALLENGE id 151 Len 27 from "asc001"
Aug 24 16:30:39.061 EST: BR1/0:1 CHAP: O RESPONSE id 151 Len 27 from "asc011"
Aug 24 16:30:39.109 EST: BR1/0:1 CHAP: I SUCCESS id 151 Len 4
 !--- Authentication is successful. 
Aug 24 16:30:39.109 EST: BR1/0:1 PPP: Phase is VIRTUALIZED [0 sess, 0 load]
Aug 24 16:30:39.113 EST: Vi1 PPP: Phase is DOWN, Setup [0 sess, 0 load]
Aug 24 16:30:39.121 EST: %LINK-3-UPDOWN: Interface Virtual-Access1,
changed state to up
Aug 24 16:30:39.121 EST: Vi1 PPP: Treating connection as a callout
Aug 24 16:30:39.121 EST: Vi1 PPP: Phase is ESTABLISHING, Active Open [0sess, 0load]
Aug 24 16:30:39.125 EST: Vi1 PPP: No remote authentication for call-out
Aug 24 16:30:39.125 EST: Vi1 LCP: O CONFREQ [Closed] id 1 Len 23
Aug 24 16:30:39.125 EST: Vi1 LCP: MagicNumber 0x55EE6079(0x050655EE6079)
Aug 24 16:30:39.125 EST: Vi1 LCP: MRRU 1524 (0x110405F4)
Aug 24 16:30:39.125 EST: Vi1 LCP: EndpointDisc 1 Local (0x130901617363303131)
Aug 24 16:30:39.129 EST: Vi1 PPP: Phase is UP [0 sess, 0 load]
Aug 24 16:30:39.129 EST: Vi1 IPCP: O CONFREQ [Closed] id 1 Len 10
Aug 24 16:30:39.129 EST: Vi1 IPCP: Address 192.168.1.111(0x0306C0A8016F)
Aug 24 16:30:39.137 EST: Vi1 IPCP: I CONFREQ [REQsent] id 1 Len 10
Aug 24 16:30:39.137 EST: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Aug 24 16:30:39.137 EST: Vi1 IPCP: O CONFACK [REQsent] id 1 Len 10
Aug 24 16:30:39.137 EST: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Aug 24 16:30:39.177 EST: Vi1 IPCP: I CONFACK [ACKsent] id 1 Len 10
Aug 24 16:30:39.177 EST: Vi1 IPCP: Address 192.168.1.111 (0x0306C0A8016F)
Aug 24 16:30:39.181 EST: Vi1 IPCP: State is Open
Aug 24 16:30:39.185 EST: BR1/0 IPCP: Install route to 192.168.1.1

!--- First call is successful. We will now initiate the additional call.

Aug 24 16:30:39.754 EST: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x3C
Aug 24 16:30:39.754 EST: Bearer Capability i = 0x8890218F
Aug 24 16:30:39.758 EST: Channel ID i = 0x83
Aug 24 16:30:39.762 EST: Keypad Facility i = '13305551111' 

!--- We once again dial out with the first dialer map (the expected behavior). !--- This call fails and router rolls over to use the second dialer map.

Aug 24 16:30:39.995 EST: ISDN BR1/0: RX <- CALL_PROC pd = 8 callref = 0xBC
Aug 24 16:30:39.995 EST: Channel ID i = 0x8A
Aug 24 16:30:39.999 EST: Locking Shift to Codeset 5
Aug 24 16:30:39.999 EST: Codeset 5 IE 0x2A i = 
  0x80880B,'13305551111',0x800109800114800114800114
Aug 24 16:30:40.111 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1,
  changed state to up
Aug 24 16:30:40.131 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access1, changed state to up
Aug 24 16:30:41.209 EST: BR1/0:1 LCP: I ECHOREQ [Open] id 1 Len 12 magic 0x8EFDDF16
Aug 24 16:30:41.209 EST: BR1/0:1 LCP: O ECHOREP [Open] id 1 Len 12 magic 0x55EE5FC7
Aug 24 16:30:42.779 EST: ISDN BR1/0: RX <- DISCONNECT pd = 8 callref = 0xBC
Aug 24 16:30:42.783 EST: Cause i = 0x8291 - User busy
Aug 24 16:30:42.783 EST: Signal i = 0x04 - Busy tone on

!--- The call fails. The remote switch sends a message that the B-channel is busy. !--- Upon receipt of this disconnect, the router dials the second dialer map. !--- If you do not receive this Disconnect within a certain timeframe, the router !--- does not attempt another call. The dialer redial or isdn fast-rollover !--- commands can fix this issue.

Aug 24 16:30:42.795 EST: %ISDN-6-CONNECT: Interface BRI1/0:1 is now connected to
  13305551111 asc001
Aug 24 16:30:42.807 EST: ISDN BR1/0: TX -> RELEASE pd = 8 callref = 0x3C
Aug 24 16:30:42.831 EST: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x3D
Aug 24 16:30:42.835 EST: Bearer Capability i = 0x8890218F
Aug 24 16:30:42.835 EST: Channel ID i = 0x83
Aug 24 16:30:42.839 EST: Keypad Facility i = '13305551112'

!--- Dial with the second dialer map.

Aug 24 16:30:42.927 EST: ISDN BR1/0: RX <- RELEASE_COMP pd = 8 callref = 0xBC
Aug 24 16:30:42.931 EST: Signal i = 0x3F - Tones off
Aug 24 16:30:43.096 EST: ISDN BR1/0: RX <- CALL_PROC pd = 8 callref = 0xBD
Aug 24 16:30:43.096 EST: Channel ID i = 0x8A
Aug 24 16:30:43.100 EST: Locking Shift to Codeset 5 asc011#
Aug 24 16:30:43.100 EST: Codeset 5 IE 0x2A i = 0x80880B, '13305551112'
  ,0x800109800114800114800114
Aug 24 16:30:46.329 EST: ISDN BR1/0: RX <- ALERTING pd = 8 callref = 0xBD
Aug 24 16:30:46.329 EST: Signal i = 0x01 - Ring back tone on
Aug 24 16:30:46.361 EST: ISDN BR1/0: RX <- CONNECT pd = 8 callref = 0xBD
Aug 24 16:30:46.361 EST: Signal i = 0x3F - Tones off
Aug 24 16:30:46.373 EST: %LINK-3-UPDOWN: Interface BRI1/0:2, changed state to up
Aug 24 16:30:46.373 EST: BR1/0:2 PPP: Treating connection as a callout
...

!--- Output omitted.

...
Aug 24 16:30:46.445 EST: BR1/0:2 LCP: State is Open
Aug 24 16:30:46.445 EST: BR1/0:2 PPP: Phase is AUTHENTICATING, by the peer 
  [0 sess, 1 load]
Aug 24 16:30:46.489 EST: BR1/0:2 CHAP: I CHALLENGE id 31 Len 27 from "asc001"
Aug 24 16:30:46.493 EST: BR1/0:2 CHAP: O RESPONSE id 31 Len 27 from "asc011"
Aug 24 16:30:46.542 EST: BR1/0:2 CHAP: I SUCCESS id 31 Len 4
Aug 24 16:30:46.542 EST: BR1/0:2 PPP: Phase is VIRTUALIZED [0 sess, 1 load]
Aug 24 16:30:46.546 EST: BR1/0:2 MLP: asc001, multilink up
Aug 24 16:30:47.343 EST: BR1/0:1 LCP: I ECHOREP [Open] id 1 Len 12 magic 
  0x8EFDDF16
Aug 24 16:30:47.343 EST: BR1/0:1 LCP: Received id 1, sent id 1, line up
Aug 24 16:30:47.343 EST: BR1/0:2 LCP: I ECHOREP [Open] id 1 Len 12 magic 
  0x8EFDFC22
Aug 24 16:30:47.347 EST: BR1/0:2 LCP: Received id 1, sent id 1, line up
Aug 24 16:30:47.543 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:2,
  changed state to up

!--- The 2 B-channel Call connects.

asc011#

Utilisez la commande show isdn active pour vérifier la connexion. Notez le numéro appelé pour chaque appel sortant. 

--------------------------------------------------------------------------------
ISDN ACTIVE CALLS
--------------------------------------------------------------------------------
Call   Calling   Called  Remote  Seconds  Seconds   Seconds  Charges
Type    Number   Number  Name     Used    Left      Idle     Units/Currency
--------------------------------------------------------------------------------
Out         +3305551111 asc001         55 Unavail    0         0
Out         +3305551112 asc001         48 Unavail    0         0
-------------------------------------------------------------------------------

Cet exemple montre un appel FAILED. Certains résultats non pertinents sont omis.


asc008#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Aug 21 09:33:17.627 EST: BR1/0 DDR: Dialing cause ip (s=192.168.1.108,d=192.168.1.1)
Aug 21 09:33:17.627 EST: BR1/0 DDR: Attempting to dial 13305551111
Aug 21 09:33:17.635 EST: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x0C
Aug 21 09:33:17.639 EST: Bearer Capability i = 0x8890
Aug 21 09:33:17.639 EST: Channel ID i = 0x83
Aug 21 09:33:17.639 EST: Keypad Facility i = '13305551111'

!--- Calling out with the number specified in the first dialer map.

Aug 21 09:33:18.184 EST: ISDN BR1/0: RX <- CALL_PROC pd = 8 callref = 0x8C
Aug 21 09:33:18.184 EST: Channel ID i = 0x89.
Aug 21 09:33:20.532 EST: ISDN BR1/0: RX <- ALERTING pd = 8 callref =0x8C
Aug 21 09:33:20.536 EST: Signal i = 0x01 - Ring back tone on
Aug 21 09:33:20.564 EST: ISDN BR1/0: RX <- CONNECT pd = 8 callref =0x8C
Aug 21 09:33:20.568 EST: Signal i = 0x3F - Tones off
Aug 21 09:33:20.572 EST: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to up
Aug 21 09:33:20.576 EST: BR1/0:1 PPP: Treating connection as a callout
Aug 21 09:33:20.580 EST: BR1/0:1 PPP: Phase is ESTABLISHING, Active Open
  [0 sess, 1 load]
...

! --Output omitted.

...
Aug 21 09:33:20.660 EST: BR1/0:1 LCP: State is Open
Aug 21 09:33:20.660 EST: BR1/0:1 PPP: Phase is AUTHENTICATING, by the peer 
  [0 sess, 1 load]
Aug 21 09:33:20.720 EST: BR1/0:1 CHAP: I CHALLENGE id 127 Len 27 from "asc001"
Aug 21 09:33:20.720 EST: BR1/0:1 CHAP: O RESPONSE id 127 Len 27 from "asc008"
Aug 21 09:33:20.784 EST: BR1/0:1 CHAP: I SUCCESS id 127 Len 4

!--- Authentication is successful.

Aug 21 09:33:20.784 EST: BR1/0:1 PPP: Phase is VIRTUALIZED [0 sess, 1 load]
Aug 21 09:33:20.784 EST: Vi1 PPP: Phase is DOWN, Setup [0 sess, 1 load]
Aug 21 09:33:20.792 EST: %LINK-3-UPDOWN: Interface Virtual-Access1,
  changed state to up
...

!--- Output omitted.

...
Aug 21 09:33:20.864 EST: Vi1 IPCP: Address 192.168.1.108(0x0306C0A8016C)
Aug 21 09:33:20.864 EST: Vi1 IPCP: State is Open
Aug 21 09:33:20.868 EST: Vi1 DDR: dialer protocol up
Aug 21 09:33:20.868 EST: BR1/0 IPCP: Install route to 192.168.1.1
Aug 21 09:33:21.089 EST: BR1/0 DDR: Attempting to dial 13305551111
Aug 21 09:33:21.093 EST: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x0D
Aug 21 09:33:21.097 EST: Bearer Capability i = 0x8890
Aug 21 09:33:21.097 EST: Channel ID i = 0x83
Aug 21 09:33:21.101 EST: Keypad Facility i = '13305551111'

!--- The second call is dialed out with the first dialer map. !--- The first B-channel on the remote BRI is in use. You must receive a !--- Disconnect(cause code:busy).

Aug 21 09:33:21.581 EST: ISDN BR1/0: RX <- CALL_PROC pd = 8 callref =0x8D
Aug 21 09:33:21.581 EST: Channel ID i = 0x8A
Aug 21 09:33:21.786 EST: %LINEPROTO-5-UPDOWN: Line protocol on 
  InterfaceBRI1/0:1, changed state to up
Aug 21 09:33:21.802 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
  Virtual -Access1, changed state to up
Aug 21 09:33:23.577 EST: ISDN BR1/0: RX <- PROGRESS pd = 8 callref = 0x8D
Aug 21 09:33:23.577 EST: Cause i = 0x8491 - User busy
Aug 21 09:33:23.581 EST: Progress Ind i = 0x8488 - In-band info or appropriate
  now available

!--- In this case, the "Rx <- PROGRESS" is returned, the CALLED !--- router does not even try to call out on the second number because the router !--- assumes the call is in progress. You must receive a DISCONNECT for the router !--- to dial the second number.

Aug 21 09:33:26.578 EST: %ISDN-6-CONNECT: Interface BRI1/0:1 is now 
  connected to 13305551111 asc001
Aug 21 09:33:51.091 EST: BRI1/0: wait for isdn carrier timeout, call  nbid=0x8010
Aug 21 09:33:51.091 EST: BR1/0 DDR: Attempting to dial 13305551112
Aug 21 09:33:51.099 EST: ISDN BR1/0: TX -> DISCONNECT pd = 8 callref = 0x0D
Aug 21 09:33:51.103 EST: Cause i = 0x8090 - Normal call clearing
Aug 21 09:33:51.147 EST: ISDN BR1/0: RX <- RELEASE pd = 8 callref = 0x8D
Aug 21 09:33:51.155 EST: ISDN BR1/0: TX -> RELEASE_COMP pd = 8 callref = 0x0Di

!--- No CONNECT follows the PROGRESS, and so the ISDN carrier times out. !--- Interestingly the ISDN dialer calls out, but the IOS !--- disconnects the same (due to the expiry of certain dialer timers).

Utilisez la commande show isdn active pour vérifier la connexion. Notez qu'une seule connexion est active.

--------------------------------------------------------------------------------
ISDN ACTIVE CALLS
--------------------------------------------------------------------------------
Call     Calling    Called    Remote    Seconds    Seconds  Seconds    Charges
Type     Number     Number     Name       Used      Left       Idle 
Units/Currency
--------------------------------------------------------------------------------
Out             +3305551111  asc001       25       Unavail      0         0
--------------------------------------------------------------------------------

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
17-Oct-2005
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits