Ce document présente des instructions sur la façon d'effectuer des bouclages afin de tester les circuits d'accès de base (BRI).
Les lecteurs de ce document devraient avoir connaissance des sujets suivants :
Sortie des commandes debug isdn q931 et debug ppp negotiation.
Concepts généraux de configuration des profils de numérotation DDR. Pour plus d'informations sur les profils de numérotation, consultez Configuration et dépannage des profils de numérotation.
Avant d'effectuer cette procédure, obtenez les informations suivantes auprès de l'opérateur téléphonique :
Type de commutateur à configurer.
Identificateurs de profil de service (SPID) et numéro de répertoire local (LDN). Le SPID et le LDN sont requis aux États-Unis d'Amérique.
Indique si les deux canaux B font partie d'un groupe de recherche. S'ils font partie d'un groupe de recherche, il suffit de composer un numéro pour atteindre l'un des canaux B.
Indique si l'appel sur la ligne BRI doit être passé à 56 000 ou 64 000
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Logiciel Cisco IOS Version 12.0(3)T et ultérieure. Ceci est dû au fait que la commande isdn call a été introduite dans le logiciel Cisco IOS Version 12.0(3)T.
Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.
Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.
Dans un appel de bouclage, le routeur compose le numéro RNIS de sa propre interface BRI (Basic Rate Interface). L'appel est acheminé vers le cloud de l'opérateur téléphonique, où l'opérateur de télécommunications bascule l'appel vers le deuxième canal BRI. Cet appel est maintenant vu par le routeur comme un appel entrant sur le deuxième canal. Par conséquent, le routeur envoie et reçoit l’appel RNIS.
Un appel de bouclage teste la capacité du routeur à initier et à mettre fin à un appel RNIS. Un appel de bouclage réussi indique clairement que le circuit RNIS vers le cloud de l'opérateur téléphonique fonctionne.
Vous pouvez effectuer deux types d'appels de bouclage pour tester un circuit BRI :
Un appel de bouclage de couche 3 RNIS ? ? ? pour laquelle vous pouvez utiliser la commande isdn call interface. Cet appel de bouclage peut vous aider à vérifier si les couches RNIS 1, 2 et 3 fonctionnent entre le routeur et le commutateur RNIS local. Ce test utilise le canal D et ne teste pas les données sur les canaux B. Cela n’implique aucune modification de la configuration du routeur. Effectuez d'abord ce test. S'il réussit, essayez le test d'appel de bouclage de données.
Un appel de bouclage de données ? ? ? qui vérifie si les canaux B peuvent effectivement transmettre des données. Ceci implique une modification de configuration sur le routeur.
Ces procédures vous permettent uniquement de vérifier si le circuit BRI vers le commutateur local est fonctionnel. Il ne teste pas la connectivité RNIS de bout en bout ni les problèmes liés au routage à établissement de connexion à la demande (DDR). Pour plus d'informations sur le dépannage des BRI, reportez-vous aux documents suivants :
Cette section fournit un exemple d'appel de bouclage de couche 3 RNIS réussi. La commande isdn call active les appels RNIS sortants sans nécessités DDR telles que le trafic et les routes intéressants. Cette commande ne peut être utilisée que pour tester le circuit RNIS jusqu’à la couche 3 et ne peut pas être utilisée pour transmettre le trafic ou comme substitution pour une configuration DDR correcte. Cette commande vérifie si le circuit RNIS, en particulier la couche 3, fonctionne.
La Figure 1 affiche le flux d'appels et certains des messages debug isdn q931 :
Figure 1 : flux d'appels et quelques messages de débogage isdn q931
maui-soho-04#isdn call interface bri 0 5551111 !--- The router dials 5551111 (the ISDN number of the router's own BRI). !--- If the BRI circuit has two different phone numbers for each B-channel, !--- use the number that belongs to the second B-channel. !--- You can use this command to make calls at 56k, with the speed 56 option . maui-soho-04# *Mar 1 17:55:08.344: ISDN BR0: TX -> SETUP pd = 8 callref = 0x09 !--- Q931 Setup message is Transmitted (TX) to the telco switch. *Mar 1 17:55:08.360: Bearer Capability i = 0x8890 *Mar 1 17:55:08.360: Channel ID i = 0x83 *Mar 1 17:55:08.364: Keypad Facility i = '5551111' *Mar 1 17:55:08.484: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x89 !--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch now processes the call. *Mar 1 17:55:08.488: Channel ID i = 0x89 *Mar 1 17:55:08.516: ISDN BR0: RX <- SETUP pd = 8 callref = 0x12 !--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call. *Mar 1 17:55:08.516: Bearer Capability i = 0x8890 *Mar 1 17:55:08.520: Channel ID i = 0x8A *Mar 1 17:55:08.520: Signal i = 0x40 - Alerting on - pattern 0 *Mar 1 17:55:08.532: Called Party Number i = 0xC1, '5551111' *Mar 1 17:55:08.532: Locking Shift to Codeset 5 *Mar 1 17:55:08.532: Codeset 5 IE 0x2A i = 0x808001038001118001, '<' *Mar 1 17:55:08.564: ISDN BR0: Event: Received a DATA call from on B2 at 64 Kb/s *Mar 1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1 *Mar 1 17:55:08.652: ISDN BR0: TX -> CALL_PROC pd = 8 callref = 0x92 ! --- Transmit (TX) a Call Proceeding message for the incoming call. *Mar 1 17:55:08.652: Channel ID i = 0x8A *Mar 1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up *Mar 1 17:55:08.988: ISDN BR0: TX -> CONNECT pd = 8 callref = 0x92 ! --- Transmit (TX) a Connect message for the incoming call. *Mar 1 17:55:08.988: Channel ID i = 0x8A *Mar 1 17:55:09.040: ISDN BR0: RX <- CONNECT_ACK pd = 8 callref = 0x12 ! --- Receive (RX) a Connect Acknowledgment for the incoming call. *Mar 1 17:55:09.040: Channel ID i = 0x8A *Mar 1 17:55:09.040: Signal i = 0x4F - Alerting off *Mar 1 17:55:09.064: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x89 ! --- Receive (RX) a Connect message for the outgoing call. *Mar 1 17:55:09.076: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x09 *Mar 1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up *Mar 1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0 *Mar 1 17:55:09.112: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5551111 ! --- Call is now connected. Loopback call is successful.
Remarques :
Au cours de l'appel de bouclage, le routeur fonctionne en tant que routeur appelé et routeur appelant sur différents canaux B. Il est important que vous gardiez un suivi de ces « rôles doubles » lorsque vous interprétez la sortie debug isdn q931. Par exemple, le routeur transmet un message de configuration (TX -> SETUP) et en reçoit un aussi (RX <- SETUP). Le message SETUP transmis doit être associé à l'appel sortant tandis que le message SETUP reçu est associé à l'appel entrant.
Dans l'exemple ci-dessus, le numéro du premier canal B est composé. Cependant, l’opérateur de téléphonie reconnaît que le premier canal B est occupé (depuis qu’il passe l’appel) et bascule l’appel vers le second canal B et que la connexion est terminée avec succès. Cependant, une configuration incorrecte dans le commutateur telco peut entraîner une défaillance de l'appel de bouclage. Cela peut se produire lorsque le commutateur tente d'attribuer l'appel au premier canal (occupé à passer l'appel). Demandez à l'opérateur de télécommunications d'ajouter les deux canaux B dans un groupe de recherche. Cependant, aux fins de ce test, nous pouvons spécifier le deuxième numéro de canal B dans la commande isdn call interface pour résoudre ce problème.
Exécutez l'appel de bouclage sur l'autre routeur.
Si les appels de bouclage aboutissent et que l'appel vers l'extrémité distante continue d'échouer, vous pouvez essayer un appel de bouclage de données pour tester l'intégrité des données du canal B comme décrit dans la section suivante.
Pour plus d'informations sur la résolution des problèmes, reportez-vous aux documents suivants :
Les appels de bouclage de données permettent de vérifier si les canaux B peuvent transmettre correctement des données. Dans de nombreuses situations, la négociation debug ppp peut échouer en permanence. Ce test peut être utilisé pour vérifier l'intégrité des données sur le canal B.
Remarque : contrairement au test précédent, ce test implique une modification de configuration du routeur.
Dans un appel de bouclage de données, nous configurons deux interfaces de numérotation sur le routeur. L'interface de numérotation est configurée avec les commandes d'adressage, d'authentification et de DDR nécessaires pour composer correctement un numéro sur la ligne BRI, recevoir l'appel entrant, se lier à l'autre interface de numérotation et se connecter correctement.
Créez un profil de numérotation pour composer un autre profil de numérotation sur le même routeur.
Pour configurer le routeur pour l'appel de bouclage, procédez comme suit :
Enregistrez la configuration en cours à l'aide de la commande copy running-config startup-config. Dans ce cas, vous pouvez redémarrer et restaurer la configuration en cours dans la version pré-test une fois le test terminé.
Configurez l'interface physique.
Remarque : Cette section suppose que vous connaissez les informations RNIS nécessaires telles que, le type de commutateur et les SPID.
interface BRI0 no ip address !--- Do not configure an IP address on the physical interface. !--- The IP address will be configured on the dialer. encapsulation ppp !--- physical interface uses PPP encapsulation dialer pool-member 1 !--- Assign BRI0 as member of dialer pool 1. !--- Dialer pool 1 is specified in interface Dialer 1, and !--- interface Dialer 2. isdn switch-type basic-ni isdn spid1 71355511110101 5551111 isdn spid2 71355511120101 5551112 !--- switch-type and SPID configuration. !--- Contact the telco for this information. ppp authentication chap callin !--- The physical interface uses CHAP authentication. !--- Authentication is required on the physical interface to bind the !--- incoming call to the right dialer profile.
Configurez la première interface de numérotation :
interface Dialer1 ip address 1.1.1.1 255.255.255.0 !--- Assign an IP address to the dialer interface. !--- In this example, the IP addresses for both dialers !--- are in the same subnet. encapsulation ppp !--- The dialer interface uses PPP (same as the physical BRI interface). dialer pool 1 !--- his defines Dialer pool 1. BRI 0 is a member of this pool. dialer remote-name dialer2 !--- This name must match the name used by the other dialer interface to !--- authenticate itself. Dialer string 7135551112. !--- Phone number for the other B-channel. !--- If your connection only needs one number for both B-channels !--- (that is, they are in a hunt-group), use that number here. dialer-group 1 !--- Apply interesting traffic definition from dialer-list 1. ppp authentication chap callin !--- Use one-way CHAP authentication. This is sufficient for this test. ppp chap hostname dialer1 !--- CHAP hostname to be sent out for authentication. ppp chap password dialer1 !--- CHAP Password to be sent out for authentication.
Configurez la deuxième interface de numérotation :
interface Dialer2 ip address 1.1.1.2 255.255.255.0 !--- Assign an IP address to the dialer interface. !--- In this example, IP address for both dialers are in the same subnet. encapsulation ppp dialer pool 1 !--- This defines Dialer pool 1. !--- BRI 0 is a member of this pool. dialer remote-name dialer1 !--- This name must match the name used by the other dialer interface !--- (dialer1) to authenticate itself. Dialer string 7135551111. !--- Phone number for the other B-channel. !--- If your connection only has one number for both B-channels !--- (that is, they are in a hunt-group), use that number here. dialer-group 1 !--- Apply interesting traffic definition from dialer-list 1. ppp authentication chap callin ppp chap hostname dialer2 !--- CHAP hostname to be sent out for authentication. ppp chap password dialer2 !--- CHAP Password to be sent out for authentication.
Configurez le nom d'utilisateur et les mots de passe pour l'authentification :
username dialer1 password 0 dialer1 username dialer2 password 0 dialer2
Le nom d'utilisateur et les mots de passe sont identiques à ceux que vous avez configurés à l'aide des commandes ppp chap hostname et ppp chap password sous chaque interface de numérotation.
Configurez les routes statiques pour plus de clarté :
ip route 1.1.1.1 255.255.255.255 Dialer1 !--- Note that the route for 1.1.1.1 points to dialer1. ip route 1.1.1.2 255.255.255.255 Dialer2 !--- Note that the route for 1.1.1.2 points to dialer2. !--- The routes are used to determine which dialer interface is !--- used for dialout.
Conseil : si vous configurez les adresses IP de l'interface Dialer 1 (Étape 3) et de l'interface Dialer 2 (Étape 4) dans des sous-réseaux distincts, les routes statiques ne sont pas nécessaires.
Configurez la définition de trafic intéressante.
dialer-list 1 protocol ip permit
Remarque : le numéro de liste de numérotation doit être identique à celui configuré dans le groupe de numérotation sous l'interface de numérotation. Dans cet exemple, configurez dialer-list 1.
Une fois le test terminé, rechargez le routeur (n'enregistrez pas la configuration) pour revenir à la configuration d'origine utilisée avant le test.
Nous allons maintenant lancer l'appel de bouclage de données et nous nous efforcerons d'achever la négociation PPP. Une négociation PPP réussie indique que les canaux B peuvent transmettre correctement les données.
Figure 2 : lancement de l'appel de bouclage de données
Activez ces débogages :
debug dialer
debug isdn q931
debug ppp negotiation
debug ppp authentication (facultatif)
Remarque : Lorsque l'appel de bouclage est en cours, le routeur fonctionne en tant que routeur appelé et routeur appelant sur différents canaux B. Il est important que vous gardiez le suivi de ces « rôles doubles » lorsque vous interprétez le résultat des commandes debug isdn q931 et debug ppp negotiation. Par exemple, le routeur transmet un message de configuration (TX -> SETUP) et en reçoit un aussi (RX <- SETUP). Le message SETUP transmis doit être associé à l'appel sortant, tandis que le message SETUP reçu est associé à l'appel entrant.
Voici les débogages de l'appel RNIS dos à dos :
router#show debug Dial on demand: Dial on demand events debugging is on PPP: PPP protocol negotiation debugging is on ISDN: ISDN Q931 packets debugging is on ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 --> 1 1 - router#ping 1.1.1.1 !--- Because of the static route entry shown in step 6 above, !--- the call is made out from dialer 1. Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: 03:40:41: BR0 DDR: rotor dialout [priority] 03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1) 03:40:41: BR0 DDR: Attempting to dial 7135551112 03:40:41: ISDN BR0: TX -> SETUP pd = 8 callref = 0x08 !--- Outgoing SETUP message. 03:40:41: Bearer Capability i = 0x8890 03:40:41: Channel ID i = 0x83 03:40:41: Keypad Facility i = '7135551112' 03:40:41: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x88 03:40:41: Channel ID i = 0x89 03:40:41: ISDN BR0: RX <- SETUP pd = 8 callref = 0x2A !--- Incoming SETUP message on the other B-channel. 03:40:41: Bearer Capability i = 0x8890 03:40:41: Channel ID i = 0x8A 03:40:41: Signal i = 0x40 - Alerting on - pattern 0 03:40:41: Called Party Number i = 0xC1, '5551112', Plan:ISDN, Type:Subscriber(local) 03:40:41: Locking Shift to Codeset 5 03:40:41: Codeset 5 IE 0x2A i = 0x808001038001118001, '<' 03:40:42: ISDN BR0: Event: Received a DATA call from on B2 at 64 Kb/s !--- Note that the call comes in on the second B-channel (BRI0:2). !--- Hence the outgoing call must have been on BRI0:1. 03:40:42: ISDN BR0: Event: Accepting the call id 0xB 03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up. 03:40:42: BR0:2 PPP: Treating connection as a callin 03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] 03:40:42: BR0:2 LCP: State is Listen !--- PPP LCP negotiations begin. 03:40:42: ISDN BR0: TX -> CALL_PROC pd = 8 callref = 0xAA 03:40:42: Channel ID i = 0x8A 03:40:42: ISDN BR0: TX -> CONNECT pd = 8 callref = 0xAA 03:40:42: Channel ID i = 0x8A 03:40:42: ISDN BR0: RX <- CONNECT_ACK pd = 8 callref = 0x2A 03:40:42: Channel ID i = 0x8A 03:40:42: Signal i = 0x4F - Alerting off 03:40:42: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x88 03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up 03:40:42: BR0:1: interface must be fifo queue, force fifo 03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 03:40:42: BR0:1 PPP: Treating connection as a callout 03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] 03:40:42: BR0:1 PPP: No remote authentication for call-out !--- One-way authentication (configured with PPP authentication CHAP callin). 03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10 03:40:42: BR0:1 LCP: MagicNumber 0x513D7870 (0x0506513D7870) 03:40:42: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x08 03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10 03:40:42: BR0:2 LCP: MagicNumber 0x513D7870 (0x0506513D7870) 03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15 03:40:42: BR0:2 LCP: AuthProto CHAP (0x0305C22305) 03:40:42: BR0:2 LCP: MagicNumber 0x513D7A45 (0x0506513D7A45) 03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10 03:40:42: BR0:2 LCP: MagicNumber 0x513D7870 (0x0506513D7870) 03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15 03:40:42: BR0:1 LCP: AuthProto CHAP (0x0305C22305) 03:40:42: BR0:1 LCP: MagicNumber 0x513D7A45 (0x0506513D7A45) 03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15 03:40:42: BR0:1 LCP: AuthProto CHAP (0x0305C22305) 03:40:42: BR0:1 LCP: MagicNumber 0x513D7A45 (0x0506513D7A45) 03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10 03:40:42: BR0:1 LCP: MagicNumber 0x513D7870 (0x0506513D7870) 03:40:42: BR0:1 LCP: State is Open 03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] 03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15 03:40:43: BR0:2 LCP: AuthProto CHAP (0x0305C22305) 03:40:43: BR0:2 LCP: MagicNumber 0x513D7A45 (0x0506513D7A45) 03:40:43: BR0:2 LCP: State is Open 03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load] !--- Authentication begins. 03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router" 03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router" 03:40:43: BR0:1 CHAP: Using alternate hostname dialer1 !--- Use the alternate hostname specified with PPP CHAP hostname !--- under int Dialer 1. 03:40:43: BR0:1 CHAP: Username router not found 03:40:43: BR0:1 CHAP: Using default password 03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1" !--- Outgoing CHAP response sent on B-channel 1. 03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1" !--- Incoming CHAP response seen on B-channel 2. 03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4 !--- Authentication is successful 03:40:43: BR0:2: interface must be fifo queue, force FIFO 03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2 !--- Call (from Dialer 1) is bound to int Dialer 2. !--- This is because the dialer remote-name dialer1 command is !--- configured under int dialer 2. Binding fails when the dialer remote-name !--- command is omitted, or is incorrect, . 03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load] !--- IPCP negotiation begins. 03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10 03:40:43: BR0:2 IPCP: Address 1.1.1.2 (0x030601010102) 03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4 03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4 03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load] 03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10 03:40:43: BR0:1 IPCP: Address 1.1.1.1 (0x030601010101) 03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4 03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10 03:40:43: BR0:1 IPCP: Address 1.1.1.2 (0x030601010102) 03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10 03:40:43: BR0:1 IPCP: Address 1.1.1.2 (0x030601010102) 03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4 03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4 03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10 03:40:43: BR0:2 IPCP: Address 1.1.1.1 (0x030601010101) 03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10 03:40:43: BR0:2 IPCP: Address 1.1.1.1 (0x030601010101) 03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4 03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4 03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10 03:40:43: BR0:2 IPCP: Address 1.1.1.2 (0x030601010102) 03:40:43: BR0:2 IPCP: State is Open !--- IPCP on B-channel 2 is Open. 03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10 03:40:43: BR0:1 IPCP: Address 1.1.1.1 (0x030601010101) 03:40:43: BR0:1 IPCP: State is Open !--- IPCP on B-channel 1 is Open. 03:40:43: BR0:2 DDR: dialer protocol up 03:40:43: BR0:1 DDR: dialer protocol up 03:40:43: Di2 IPCP: Install route to 1.1.1.1 03:40:43: Di1 IPCP: Install route to 1.1.1.2 03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up 03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up !--- Both B-channels are up. ... Success rate is 0 percent (0/5) router#
Remarque : les requêtes ping peuvent échouer en raison de problèmes liés au routage. Vous pouvez vous attendre à ceci. La négociation PPP réussie est le véritable test pour savoir si les canaux B peuvent transmettre correctement les données sur la liaison. Si l'appel échoue, contactez l'opérateur téléphonique pour obtenir plus d'informations sur la façon de dépanner la ligne.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
09-Sep-2005 |
Première publication |