Loopback-oproepen uitvoeren om BRI-circuits te testen

Downloadopties

  • PDF     (237.4 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (113.1 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (257.8 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:9 september 2005
Document-id:22802

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

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:

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

bri_loopback_call1.gif 

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:

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

bri_loopback_call2.gif

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

Revisiegeschiedenis

Revisie Publicatiedatum Opmerkingen
1.0
09-Sep-2005
Eerste vrijgave

Was dit document nuttig?

FeedbackFeedback

Contact Cisco

Dit document is van toepassing op deze producten