Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Description du problème

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

Dépannage

Exemple de sortie

Informations connexes

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 :

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 :

Configurez une Un numéro :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.

Sur le routeur local, configurez une Deux numéros :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. Les deux numéros de canal B sont-ils configurés dans un groupe de recherche ?Question :

Réponse :

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. Oui:

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 Non: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.

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

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 :

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

- Multilink PPP pour DDR - Configuration de base et vérification

- Organigramme du dépannage BRI RNIS

- Dépannage de la couche 3 de l'accès de base RNIS à l'aide de la commande debug isdn q931

- Comment accélérer l'ajout de canaux B RNIS à un ensemble Multilink PPP

- Support et documentation techniques - Cisco Systems