Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Achtergrondinformatie

Een ISDN Layer 3 gespreksronde uitvoeren

Een gespreksbericht voor gegevensstromen uitvoeren

De router configureren

De gegevensback-up starten

Gerelateerde informatie

Inleiding

Dit document bevat instructies hoe u loopbacks kunt uitvoeren om de (BRI) circuits van de Basissnelheid te testen.

Voorwaarden

Vereisten

Lezers van dit document zouden kennis moeten hebben van deze onderwerpen:

- De uitvoer van de debug-opdrachten van ISDN Q931 en debug van ppp-onderhandeling.

- Algemeen DDR dialer-profielconfiguratie. Zie Kiezerprofielen configureren en probleemoplossing voor meer informatie over dialoogvensterprofielen.

Alvorens deze procedure te starten, dient u de volgende informatie te verkrijgen van Telco:

- Switch-type dat moet worden geconfigureerd.

- Identificatoren van serviceprofiel (SPID) en het plaatselijke telefoonnummer (LDN). De SPID en LDN zijn vereist in de Verenigde Staten van Amerika.

- Of beide B-kanalen in een jachtgroep zitten. Als ze in een jachtgroep zitten, hoeven we maar één nummer te bellen om een B-kanaal te bereiken.

- Of de oproep op de BRI-lijn moet worden gedaan op 56k of 64k

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

- Cisco IOS-softwarerelease 12.0(3)T en hoger Dit komt doordat de ISDN-gespreksopdracht is geïntroduceerd in Cisco IOS-softwarerelease 12.0(3)T.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.

Conventies

Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.

Achtergrondinformatie

In een loopback vraag, wijst de router het aantal van ISDN van zijn eigen BasisInterface (BRI) terug. De oproep gaat naar de telco-cloud, waar de telco de oproep naar het tweede BRI-kanaal switch. Deze vraag wordt nu door de router gezien als een inkomend gesprek op het tweede kanaal. Daarom wordt de router zowel verzonden als ontvangen door ISDN.

Een loopback vraag test de mogelijkheid van de router om een ISDN-vraag te openen en te beëindigen. Een succesvolle loopback vraag geeft u een sterke aanwijzing dat het ISDN-circuit naar de telco-cloud functioneel is.

Er zijn twee types van Loopback Roepingen die u kunt uitvoeren om een BRI kring te testen:

- Een ISDN Layer 3 loopback-gesprek??? waarvoor u de ISDN-opdracht kunt gebruiken om interface te bellen. Deze loopback vraag kan u helpen om te verifiëren of de Lagen 1, 2, en 3 van ISDN tussen de router en de lokale switch van ISDN functioneel zijn. Deze test gebruikt het D-kanaal en test geen gegevens over de B-kanalen. Dit impliceert geen veranderingen in de configuratie van de router. Voer eerst deze test uit. Als het slaagt, probeer de data loopback call test.

- Een telefoontje met gegevens??? die testen of de B-kanalen gegevens kunnen doorgeven. Dit impliceert een configuratieverandering op de router.

Deze procedures staan u alleen toe om te testen of het BRI-circuit naar de lokale switch functioneel is. Het test geen end-to-end ISDN connectiviteit of kwesties gerelateerd aan wijzerplaat-op-vraag routing (DDR). Raadpleeg voor meer informatie over het oplossen van BRI’s de volgende documenten:

- ISDN BRI-stromen voor probleemoplossing

- ISDN BRI Layer 3 probleemoplossing met de debug-opdracht van ISDN Q931

Een ISDN Layer 3 gespreksronde uitvoeren

Deze sectie verschaft een voorbeeld van een succesvolle ISDN Layer 3 loopback-vraag. De ISDN aanroep opdracht maakt uitgaande ISDN-oproepen mogelijk zonder DDR-vereisten zoals interessant verkeer en routes. Deze opdracht kan alleen worden gebruikt om het ISDN-circuit te testen tot aan Layer 3, en kan niet worden gebruikt om verkeer door te geven of als vervanging voor een juiste DDR-configuratie. Deze opdracht verifieert of het ISDN-circuit, met name Layer 3, functioneel is.

Afbeelding 1 toont de Call Flow en enkele van de debug-berichten van ISDN Q931:

Afbeelding 1 - De Call Flow en sommige debug van ISDN Q931-berichten

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.

Opmerkingen:

- Tijdens de loopback vraag, voert de router als zowel de geroepen router als de Roepende router op verschillende B-kanalen uit. Het is belangrijk dat u deze "dubbele rollen" bijhoudt wanneer u de debug-uitvoer van ISDN Q931 interpreteert. De router stuurt bijvoorbeeld een setup-bericht (TX -> SETUP) en ontvangt een bericht (RX <-SETUP). De verzonden SETUP moet worden gekoppeld aan de uitgaande oproep terwijl het ontvangen SETUP-bericht gekoppeld is aan de inkomende oproep.

- In het bovenstaande voorbeeld wordt het nummer voor het eerste B-kanaal geselecteerd. Echter, telco erkent dat het eerste B-kanaal bezig is (sinds het de vraag maakt), en switch de vraag naar het tweede B-kanaal en de verbinding wordt voltooid. Een onjuiste configuratie in de telco switch kan echter resulteren in een storing van de loopback-aanroep. Dit kan voorkomen wanneer de switch probeert de vraag aan het eerste kanaal toe te wijzen (dat het druk heeft om de vraag te maken). Vraag het telco om beide B-kanalen in een jachtgroep toe te voegen. Voor deze test kunnen we echter het tweede B-kanaalnummer in de opdracht ISDN-aanspreekinterface specificeren om rond deze kwestie te werken.

- Voer de loopback aanroep op de andere router uit.

- Als de loopback aanroepen slagen en de aanroep naar het externe einde blijft mislukken, kunt u een gegevensloopback aanroep proberen om B-kanaal gegevensintegriteit te testen zoals in de volgende sectie beschreven wordt.

Raadpleeg deze documenten voor informatie over het oplossen van problemen:

- ISDN BRI-stromen voor probleemoplossing

- ISDN BRI Layer 3 probleemoplossing met de debug van ISDN Q931-opdracht

Een gespreksbericht voor gegevensstromen uitvoeren

Data Loopback Call is handig om te testen of de B-kanalen gegevens correct kunnen verzenden. In veel situaties kunnen debug-onderhandeling continu falen. Deze test kan worden gebruikt om de gegevensintegriteit op het B-kanaal te controleren.

Opmerking: Deze test, in tegenstelling tot de vorige test, heeft betrekking op een configuratiewijziging in de router.

In een Bel van de Loopback van Gegevens, vormen wij twee dialerinterfaces op de router. De dialerinterface wordt geconfigureerd met de benodigde adressering, verificatie en DDR-opdrachten om met succes uit te bellen op de BRI-lijn, de inkomende oproep te ontvangen, zich te binden aan de andere dialerinterface en succesvol verbinding te maken.

Maak een dialerprofiel om een ander dialerprofiel op dezelfde router te bellen.

De router configureren

Om de router voor de loopback vraag te vormen, voltooien deze stappen:

1. Bewaar de actieve configuratie met de hulp van het van de kopieer in werking stellen -in werking stellen -configuratie bevel. Wanneer u dit wel doet, kunt u de actieve configuratie opnieuw opstarten en terugzetten naar de pre-testversie nadat de test is voltooid.

2. Configureer de fysieke interface.

N.B.: Deze sectie veronderstelt dat u de benodigde ISDN-gerelateerde informatie zoals, switch-type en SPIDs weet.

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.

3. Configuratie van de eerste dialerinterface:

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.

4. Configuratie van de tweede dialerinterface:

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.

5. Configureer de gebruikersnaam en de wachtwoorden voor verificatie:

username dialer1 password 0 dialer1

username dialer2 password 0 dialer2

De gebruikersnaam en de wachtwoorden zijn hetzelfde als de wachtwoorden die u met de opdrachten ppp chap hostname en ppp chap password onder elke dialerinterface hebt ingesteld.

6. Statische routes voor helderheid configureren:

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.

Tip: Als u de IP-adressen voor interface-snelkiezer 1 (Stap 3) en interface-snelkiezer 2 (Stap 4) in afzonderlijke subnetten configureren zijn de statische routes niet nodig.

7. Configureer de interessante verkeersdefinitie.

dialer-list 1 protocol ip permit

Opmerking: het dialer-list nummer moet hetzelfde zijn als het nummer dat in dialergroep onder de dialerinterface is ingesteld. In dit voorbeeld, moet u een dialerlijst 1 configureren.

8. Wanneer de test is voltooid, laadt u de router (slaat de configuratie niet op) om terug te keren naar de oorspronkelijke configuratie die voor de test is gebruikt.

De gegevensback-up starten

We zullen nu de datalink-oproep openen en op zoek gaan naar een succesvolle afronding van de PPP-onderhandelingen. Een succesvolle PPP-onderhandeling geeft aan dat de B-kanalen gegevens correct kunnen doorgeven.

Afbeelding 2 - initieert de oproep voor het indienen van gegevens

Activeer deze apparaten:

- dialer debug

- debug van ISDN Q931

- debug van PPP-onderhandeling

- debug van PPP-verificatie (optioneel)

Opmerking: Wanneer de terugloopvraag in uitvoering is, voert de router uit zoals zowel de geroepen router als de Roepende router op verschillende B-kanalen. Het is belangrijk dat u deze "dubbele rollen" bijhoudt wanneer u de uitvoer van de debug ISDN q931 interpreteert en de opdrachten van de PPP-onderhandeling debug houdt. De router stuurt bijvoorbeeld een setup-bericht (TX -> SETUP) en ontvangt een bericht (RX <-SETUP). De verzonden SETUP moet worden gekoppeld aan de uitgaande oproep, terwijl het ontvangen SETUP-bericht gekoppeld is aan de inkomende oproep.

Hier zijn de debugs voor het back-to-back ISDN-gesprek:

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#

Opmerking: pings kunnen mislukken vanwege problemen met betrekking tot routing. Je kunt dit verwachten. De succesvolle PPP-onderhandeling is de echte test of de B-kanalen gegevens op de juiste manier over de link kunnen doorgeven. Als de oproep mislukt, neemt u contact op met de telco voor meer informatie over hoe u de regel kunt oplossen.

Gerelateerde informatie

- ISDN BRI-stromen voor probleemoplossing

- ISDN BRI Layer 3 probleemoplossing met de debug van ISDN Q931-opdracht

- Kiezerprofielen configureren en oplossen

- PPP-verificatie met behulp van de ppp chap hostname en ppp-verificatie ketting om opdrachten aan te roepen

- Ondersteuning van inbel- en toegangstechnologie

- Technische ondersteuning en documentatie – Cisco Systems