BRI 회로 테스트를 위한 루프백 통화 수행

다운로드 옵션

  • PDF     (258.8 KB)
    다양한 디바이스에서 Adobe Reader로 보기
  • ePub     (108.7 KB)
    iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
  • Mobi (Kindle)     (254.6 KB)
    Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기
업데이트:2005년 9월 9일
문서 ID:22802

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 BRI(Basic Rate Interface) 회로를 테스트하기 위해 루프백을 수행하는 방법에 대한 지침을 제공합니다.

사전 요구 사항

요구 사항

이 문서의 독자는 다음 주제에 대해 알고 있어야 합니다.

  • debug isdn q931 및 debug ppp 협상 명령의 출력입니다.

  • 일반 DDR 다이얼러 프로파일 구성 개념. 다이얼러 프로파일에 대한 자세한 내용은 다이얼러 프로파일 구성 및 문제 해결을 참조하십시오.

이 절차를 시도하기 전에 Telco에서 다음 정보를 얻으십시오.

  • 구성할 스위치 유형입니다.

  • SPID(서비스 프로필 식별자) 및 LDN(로컬 디렉터리 번호)입니다. SPID와 LDN은 미국에서 필요합니다.

  • 두 B 채널이 모두 헌트 그룹에 있는지 여부. 헌트 그룹에 있는 경우 B-채널 중 하나에 연결하기 위해 한 번만 전화를 걸면 됩니다.

  • BRI 회선의 통화를 56k 또는 64k로 해야 하는지 여부

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

  • Cisco IOS Software 릴리스 12.0(3)T 이상 이는 isdn call 명령이 Cisco IOS Software Release 12.0(3)T에 도입되었기 때문입니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

배경 정보

루프백 통화에서 라우터는 자체 BRI(Basic Rate Interface)의 ISDN 번호로 전화를 겁니다. 통화가 텔코 클라우드로 진행되며, 여기서 telco는 통화를 두 번째 BRI 채널로 전환합니다. 이제 라우터에서 이 통화를 두 번째 채널의 수신 통화로 볼 수 있습니다. 따라서 라우터는 ISDN 통화를 보내고 받습니다.

루프백 통화는 라우터가 ISDN 통화를 시작하고 종료하는 기능을 테스트합니다. 루프백 호출이 성공하면 텔코 클라우드에 대한 ISDN 회로가 작동함을 강력하게 나타냅니다.

BRI 회로를 테스트하기 위해 수행할 수 있는 루프백 통화에는 두 가지 유형이 있습니다.

  • ISDN Layer 3 루프백 호출 를 사용하여 isdn call interface 명령을 사용할 수 있습니다. 이 루프백 호출을 통해 ISDN Layers 1, 2 및 3이 라우터와 로컬 ISDN 스위치 간에 작동하는지 확인할 수 있습니다. 이 테스트에서는 D 채널을 사용하며 B 채널 전체에서 데이터를 테스트하지 않습니다. 여기에는 라우터 컨피그레이션이 변경되지 않습니다. 먼저 이 테스트를 수행합니다. 성공하면 데이터 루프백 호출 테스트를 시도합니다.

  • 데이터 루프백 호출 B 채널이 실제로 데이터를 전달할 수 있는지 여부를 테스트합니다. 여기에는 라우터의 컨피그레이션 변경이 포함됩니다.

이 절차에서는 로컬 스위치에 대한 BRI 회로의 작동 여부를 테스트할 수 있습니다. 엔드 투 엔드 ISDN 연결이나 DDR(Dial-on-demand routing)과 관련된 문제는 테스트하지 않습니다. BRI 문제 해결에 대한 자세한 내용은 다음 문서를 참조하십시오.

ISDN Layer 3 루프백 통화 수행

이 섹션에서는 ISDN Layer 3 루프백 호출에 성공한 예를 제공합니다. isdn call 명령은 흥미로운 트래픽 및 경로와 같은 DDR 요구 사항 없이 발신 ISDN 통화를 활성화합니다. 이 명령은 레이어 3까지 ISDN 회로를 테스트하는 데만 사용할 수 있으며 트래픽을 전달하는 데 또는 적절한 DDR 구성을 대체하는 용도로 사용할 수 없습니다. 이 명령은 ISDN 회로(특히 레이어 3)가 작동하는지 확인합니다.

그림 1은 통화 흐름과 일부 디버그 isdn q931 메시지를 표시합니다.

그림 1 - 통화 흐름 및 일부 디버그 isdn q931 메시지

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.

참고:

  • 루프백 통화 중에 라우터는 서로 다른 B 채널에서 Called Router와 Calling Router의 역할을 모두 수행합니다. debug isdn q931 출력을 해석할 때 이러한 "이중 역할"을 계속 추적하는 것이 중요합니다. 예를 들어, 라우터는 설정 메시지(TX -> SETUP)를 전송하고 동일한 메시지를 수신합니다(RX <- SETUP). 수신된 SETUP 메시지가 수신 통화에 연결된 동안 전송된 SETUP을 발신 통화에 연결해야 합니다.

  • 위 예에서 첫 번째 B-채널의 번호로 전화를 겁니다. 그러나 Telco는 첫 번째 B 채널이 통화 중임을 인식하고(통화 중이기 때문) 통화를 두 번째 B 채널로 전환하고 연결이 성공적으로 완료됩니다. 그러나 텔코 스위치의 컨피그레이션이 잘못되면 루프백 호출이 실패할 수 있습니다. 이 문제는 스위치가 통화를 통화 중인 첫 번째 채널에 통화를 할당하려고 할 때 발생할 수 있습니다. B-채널을 모두 헌트 그룹에 추가하도록 통신사에 요청합니다. 그러나 이 테스트에서는 이 문제를 해결하기 위해 isdn call interface 명령에 두 번째 B-channel 번호를 지정할 수 있습니다.

  • 다른 라우터에서 루프백 통화를 수행합니다.

  • 루프백 호출이 성공하고 원격 끝으로의 호출이 계속 실패하는 경우 다음 섹션에 설명된 대로 데이터 루프백 호출을 시도하여 B-채널 데이터 무결성을 테스트할 수 있습니다.

문제 해결 방법에 대한 자세한 내용은 다음 문서를 참조하십시오.

데이터 루프백 호출 수행

데이터 루프백 통화는 B 채널이 데이터를 올바르게 전송할 수 있는지 여부를 테스트하는 데 유용합니다. 많은 경우 디버그 ppp 협상이 계속 실패할 수 있습니다. 이 테스트는 B-채널의 데이터 무결성을 확인하는 데 사용할 수 있습니다.

참고: 이 테스트에서는 이전 테스트와 달리 라우터에 대한 컨피그레이션 변경이 포함됩니다.

Data Loopback Call(데이터 루프백 호출)에서는 라우터에 두 개의 다이얼러 인터페이스를 구성합니다. 다이얼러 인터페이스는 필요한 주소 지정, 인증 및 DDR 명령으로 구성되어 BRI 회선에서 성공적으로 다이얼아웃하고, 수신 통화를 수신하고, 다른 다이얼러 인터페이스에 바인딩하고, 성공적으로 연결합니다.

동일한 라우터에서 다른 다이얼러 프로필에 다이얼러 프로파일을 생성합니다.

라우터 구성

루프백 통화에 대한 라우터를 구성하는 절차는 다음과 같습니다.

  1. copy running-config startup-config 명령의 도움말을 사용하여 실행 중인 컨피그레이션을 저장합니다. 그러면 테스트가 완료된 후 실행 중인 컨피그레이션을 재부팅하고 테스트 전 버전으로 복원할 수 있습니다.

  2. 물리적 인터페이스를 구성합니다.

    참고: 이 섹션에서는 스위치 유형 및 SPID와 같은 필요한 ISDN 관련 정보를 알고 있다고 가정합니다. 

    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. 첫 번째 다이얼러 인터페이스를 구성합니다. 

    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. 두 번째 다이얼러 인터페이스를 구성합니다. 

    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. 인증을 위한 사용자 이름 및 비밀번호를 구성합니다. 

    username dialer1 password 0 dialer1
username dialer2 password 0 dialer2

    사용자 이름 및 비밀번호는 ppp chap 호스트 이름 및 ppp chap password 명령을 사용하여 구성한 각 다이얼러 인터페이스에서 구성한 것과 동일합니다.

  6. 명확성을 위해 고정 경로를 구성합니다.

    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.

    팁: 별도의 서브넷에서 인터페이스 다이얼러 1(3단계) 및 인터페이스 다이얼러 2(4단계)에 대한 IP 주소를 구성하는 경우 고정 경로가 필요하지 않습니다.

  7. 흥미로운 트래픽 정의를 구성합니다. 

    dialer-list 1 protocol ip permit

    참고: 다이얼러 목록 번호는 다이얼러 인터페이스의 다이얼러 그룹에 구성된 번호와 동일해야 합니다. 이 예에서는 dialer-list 1을 구성합니다.

  8. 테스트가 완료되면 라우터를 다시 로드(컨피그레이션을 저장하지 않음)하여 테스트 전에 사용된 원래 컨피그레이션으로 돌아갑니다.

데이터 루프백 통화 시작

이제 데이터 루프백 호출을 시작하고 PPP 협상이 성공적으로 완료되었는지 확인합니다. 성공적인 PPP 협상은 B 채널이 데이터를 올바르게 전달할 수 있음을 나타냅니다.

그림 2 - 데이터 루프백 통화 시작

bri_loopback_call2.gif

다음 디버그를 활성화합니다.

  • 디버그 다이얼러

  • 디버그 isdn q931

  • 디버그 ppp 협상

  • debug ppp authentication(선택 사항)

참고: 루프백 호출이 진행 중일 때 라우터는 서로 다른 B 채널에서 발신된 라우터와 발신 라우터의 역할을 수행합니다. debug isdn q931 및 debug ppp negotiation 명령의 출력을 해석할 때 이러한 "이중 역할"을 계속 추적하는 것이 중요합니다. 예를 들어, 라우터는 설정 메시지(TX -> SETUP)를 전송하고 동일한 메시지를 수신합니다(RX <- SETUP). 전송된 SETUP은 발신 통화와 연결되어야 하며, 수신된 SETUP 메시지는 수신 통화와 연결되어야 합니다.

다음은 백투백 ISDN 통화에 대한 디버그입니다.

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#

참고: 라우팅과 관련된 문제로 인해 ping이 실패할 수 있습니다. 이런 걸 기대할 수 있어요 성공적인 PPP 협상은 B 채널이 링크의 데이터를 올바르게 전달할 수 있는지 여부를 확인하는 진정한 테스트입니다. 통화가 실패할 경우, 회선 문제 해결 방법에 대한 자세한 내용은 통신사에 문의하십시오.

관련 정보

개정 이력

개정 게시 날짜 의견
1.0
09-Sep-2005
최초 릴리스

이 문서가 도움이 되셨습니까?

Feedback피드백

지원 문의

이 문서가 적용되는 제품