ISDN BRI 문제 해결 흐름도

다운로드 옵션

  • PDF     (314.4 KB)
    다양한 디바이스에서 Adobe Reader로 보기
  • ePub     (115.3 KB)
    iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
  • Mobi (Kindle)     (309.1 KB)
    Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기
업데이트:2016년 6월 27일
문서 ID:20602

편견 없는 언어

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

이 번역에 관하여

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

소개

이 문서는 ISDN BRI(Basic Rate Interface) 전화 접속 액세스 문제를 해결하는 데 도움이 됩니다.아래 표시된 순서도 및 샘플 출력에서 다이얼러 프로파일을 사용하여 다른 ISDN BRI 연결을 설정했습니다.그러나 다른 라우터(예: 지사)와의 연결과 레거시 DDR(Dial-on-Demand Routing)을 사용하는 경우에도 동일한 문제 해결 단계가 적용됩니다.

참고:또한 Cisco Support Community를 사용하여 ISDN 문제를 해결할 수도 있습니다.

ISDN 및 DDR에 대한 소개 정보는 Cisco Learning Connection에 있는 오디오 교육을 참조하십시오.

순서도

항목에 대한 자세한 내용을 보려면 아래 링크를 클릭하십시오.브라우저의 뒤로 단추를 사용하여 이 순서도로 돌아갑니다.

20602-isdn-20602-00.gif

login routerdial routernotdial isdnconnect isdnnotconnect pppsucceed pppnotsucceed pppauthsucceed pppauthnotsucceed ipcpcomplete ipcpnotsucceed

문제 해결:이러한 디버그를 로그인 및 캡처하는 방법

PC의 직렬 포트에 연결된 콘솔 케이블을 통해 또는 텔넷을 사용하여 라우터에 연결할 수 있습니다.

콘솔을 통해 라우터에 연결해야 하는 경우 콘솔 연결에 대한 올바른 터미널 에뮬레이터 설정 적용을 참조하십시오.라우터가 이더넷에 연결되도록 이미 설정되어 있고 텔넷을 사용하여 라우터에 연결하려면 텔넷 클라이언트를 사용하여 라우터의 이더넷 IP 주소에 연결하기만 하면 됩니다.

어떤 경우든(콘솔 또는 텔넷), 특정 메시지를 찾기 위해 디버그 출력에서 다시 스크롤해야 할 수 있으므로 세션 중에 받은 출력 기록을 유지할 수 있는 클라이언트를 사용하는 것이 좋습니다.

디버그 출력 및 로그 메시지에서 밀리초를 활성화합니다.프롬프트가 표시되면 라우터에 구성된 비밀번호를 입력하고 enable 모드를 시작합니다.

router>enable
Password: (enter the enable password)
router#
router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router(config)#service timestamps debug datetime msec 
router(config)#service timestamps log datetime msec

텔넷을 사용하여 연결된 경우 다음과 같이 terminal monitor를 입력합니다.

router#terminal monitor
router#

이렇게 하려면 아래에 debug 명령을 입력합니다.

router#debug isdn q931
ISDN Q931 packets debugging is on
router#debug ppp negotiation
PPP protocol negotiation debugging is on
router#debug dialer packet
Dial on demand packets debugging is on
router#debug dialer
Dial on demand events debugging is on
router#debug ppp authentication
PPP authentication debugging is on
router#

그런 다음 발신 라우터에서 ping을 시작합니다.다음은 성공한 통화의 샘플 디버그 출력입니다.순서도에서 식별된 다른 단계가 강조 표시됩니다.

router#ping 194.183.201.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds:

*Mar  1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 
100 bytes, outgoing interesting (ip PERMIT)
! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1)
*Mar  1 00:06:36.387: BR0 DDR: rotor dialout [priority]
*Mar  1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1)
*Mar  1 00:06:36.395: BR0 DDR: Attempting to dial 8134
! -- Number used to dial. 
! -- This is configured using the dialer string or dialer map command 
! -- If you do not see this message proceed to section 
! -- Symptom: The Router Does Not Attempt to Dial
*Mar  1 00:06:36.411: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x02
*Mar  1 00:06:36.415:         Bearer Capability i = 0x8890
*Mar  1 00:06:36.423:         Channel ID i = 0x83
*Mar  1 00:06:36.427:         Called Party Number i = 0x80, '8134',
Plan:Unknown, Type:Unknown
*Mar  1 00:06:36.519: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x82
*Mar  1 00:06:36.527:         Channel ID i = 0x89
*Mar  1 00:06:36.727: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x82
*Mar  1 00:06:36.743: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x02
*Mar  1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
! -- ISDN Layer 3 CONNECT message and Link Up message
! -- If you do not see this message proceed to section 
! -- Symptom: The ISDN Call Does Not Connect Successfully
*Mar  1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo
*Mar  1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
*Mar  1 00:06:36.787: BR0:1 PPP: Treating connection as a callout
*Mar  1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open
! -- LCP negotiation begins
*Mar  1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out
*Mar  1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar  1 00:06:36.799: BR0:1 LCP:    MagicNumber 0x0012586A (0x05060012586A)
*Mar  1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15
*Mar  1 00:06:36.863: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:36.867: BR0:1 LCP:    MagicNumber 0x10D36A4C (0x050610D36A4C)
*Mar  1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15
*Mar  1 00:06:36.875: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:36.875: BR0:1 LCP:    MagicNumber 0x10D36A4C (0x050610D36A4C)
*Mar  1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10
*Mar  1 00:06:36.883: BR0:1 LCP:    MagicNumber 0x0012586A (0x05060012586A)
*Mar  1 00:06:36.887: BR0:1 LCP: State is Open
! -- LCP negotiation is complete. Any LCP state other than Open indicates 
! -- that LCP negotiation has failed. 
! -- If you do not see this message proceed to section 
! -- Symptom: PPP LCP Phase Does Not Succeed
*Mar  1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer
*Mar  1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP"
! -- Incoming CHAP challenge
*Mar  1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX
! -- Using alternate hostname configured with ppp chap hostname command 
*Mar  1 00:06:36.915: BR0:1 CHAP: Username ISP not found
*Mar  1 00:06:36.919: BR0:1 CHAP: Using default password
! -- Using password configured with ppp chap password command
*Mar  1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX"
! -- Sending response from "XXXXX" which is the alternate hostname for the router
*Mar  1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4
! -- NAS has succesfully authenticated the router
*Mar  1 00:06:36.943: BR0:1 PPP: Phase is UP
! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins
*Mar  1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10
*Mar  1 00:06:36.951: BR0:1 IPCP:    Address 0.0.0.0 (0x030600000000)
! -- This router does not have an address configured, so it sends a 
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address 
! -- which is accomplished by the sending of a CONFNAK with the proper address.
*Mar  1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10
*Mar  1 00:06:36.963: BR0:1 IPCP:    Address 194.183.201.1 (0x0306C2B7C901)
! -- Incoming CONFREQ indicating the peer's IP address
*Mar  1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10
*Mar  1 00:06:36.971: BR0:1 IPCP:    Address 194.183.201.1 (0x0306C2B7C901)
! -- The router accepts the peer's IP address 
! -- (since it is not trying to assign one to the peer) 
! -- Once the call is connected a route to this address will be installed
*Mar  1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10
*Mar  1 00:06:36.979: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)
! -- The peer CONFNAKs our initial Address request of 0.0.0.0 
! -- It responds with the address that this router could use 
! -- The NAS can assign this using the peer default ip address or dialer map command
*Mar  1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10
*Mar  1 00:06:36.987: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)
! -- This router requests the address previously suggested by the NAS
*Mar  1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.015: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)
! -- NAS accepts the address requested by the client
*Mar  1 00:06:37.015: BR0:1 IPCP: State is Open
! -- PPP NCP (IPCP) negotiation is complete
! -- If you do not see this message proceed to section 
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed
*Mar  1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address
194.183.201.2
*Mar  1 00:06:37.031: BR0:1 DDR: dialer protocol up
*Mar  1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1
! -- Route to peer is installed
*Mar  1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to up
*Mar  1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,
outgoing interesting (ip PERMIT)
*Mar  1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,
outgoing interesting (ip PERMIT)
*Mar  1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,
outgoing interesting (ip PERMIT)
*Mar  1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes,
outgoing interesting (ip PERMIT)
router#
*Mar  1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134
unknown
router#

문제 해결 순서도로 돌아가기

문제 해결:라우터가 다이얼을 시도합니까?

라우터가 통화를 시도하는지 여부를 확인하려면 발신 라우터의 디버그 출력에 다음 행이 있는지 확인합니다.

*Mar  1 00:06:36.395: BR0 DDR: Attempting to dial 8134

디버그 출력에서 8134는 라우터가 다이얼하려는 ISDN 디렉토리 번호입니다.이 번호는 다이얼러 문자열 또는 다이얼러 맵 명령을 사용하여 지정되었습니다.

문제 해결 순서도로 돌아가기

증상:라우터가 다이얼을 시도하지 않음

라우터가 다이얼을 시도하지 않는 경우 다음과 같은 몇 가지 가능성이 있습니다.

디버그 출력이 전혀 없습니다.

디버그 출력이 전혀 없는 경우 전송 중인 IP 패킷이 다이얼러 인터페이스로 라우팅되지 않기 때문일 수 있습니다.가장 일반적인 원인은 다음과 같습니다.

  • 다이얼러 인터페이스에 IP가 구성되어 있는지 확인합니다.다이얼러 인터페이스에 IP 주소가 있거나 IP 번호가 지정되지 않은 인터페이스(인터페이스는 이더넷 x, 루프백x 등과 같은 up/up 인터페이스) 또는 협상된 IP 주소(클라이언트가 NAS에서 IP 주소를 가져오는 경우)가 있어야 합니다. 레거시 DDR을 사용하는 경우 물리적 인터페이스(예: 인터페이스 BRI 0)에서 IP 주소를 구성해야 합니다.
  • 명령 ip 라우팅이 구성되었는지 확인합니다.show running-config 명령을 사용하여 컨피그레이션을 볼 때 no ip routing 명령을 볼 수 없습니다.
  • 다이얼러 인터페이스 또는 next hop(다이얼러 맵을 사용하는 경우)을 가리키는 고정 경로가 있는지 확인합니다.

    다음 예(다이얼러 프로파일의 경우)는 다음 hop 다이얼러 1을 사용하는 172.22.53.0/24의 고정 경로입니다.

    maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1

    다음 예(레거시 DDR의 경우)는 다음 홉이 172.16.1.1인 172.22.53.0/24에 대한 고정 경로입니다. 다음 hop 주소는 다이얼에 사용되는 다이얼러 맵 문의 ip 주소와 일치해야 합니다.

    maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
  • 다이얼러 또는 물리적 인터페이스가 관리 목적으로 다운되거나 대기 상태가 아닌지 확인합니다.show interface dialer X 또는 show interface bri X 명령을 사용하여 인터페이스가 up/up(스푸핑) 상태인지 확인합니다.

    인터페이스가 관리 목적으로 다운된 경우 인터페이스 컨피그레이션 모드에서 no shutdown 명령을 사용합니다.

    인터페이스가 대기 상태인 경우 다이얼러 또는 BRI 인터페이스는 작동 중인 연결에 대한 백업입니다.기본 인터페이스 아래에서 backup interface 명령을 제거하거나 기본 인터페이스에서 케이블을 잡아당길 수 있습니다.

디버그 출력이 있지만 "전화 걸기 시도" 메시지가 없습니다.

이 경우 인터페이스에 라우팅된 IP 패킷이 있을 수 있지만 라우터가 이를 폐기하고 어떤 이유로 통화를 시작하지 않습니다.디버그 출력을 확인하여 통화 시도가 수행되지 않는 이유를 확인합니다.다음은 몇 가지 샘플 디버그 출력 및 가능한 이유입니다.

예 1

*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1),
  100 bytes, outgoing uninteresting (list 101).

생성된 트래픽이 흥미로운 트래픽 정의와 일치하지 않습니다.이 예에서는 access-list 101을 수정합니다.

다음과 같이 모든 IP 트래픽을 허용하는 것이 간단한 트래픽 정의입니다.

maui-soho-01(config)#dialer-list 1 protocol ip permit

경고:모든 IP 트래픽을 흥미로운 것으로 표시하면 특히 라우팅 프로토콜 또는 기타 주기적인 트래픽이 있는 경우 ISDN 링크가 무기한 작동할 수 있습니다.필요에 맞게 흥미로운 트래픽 정의를 조정합니다.

흥미로운 트래픽에 대한 자세한 내용은 Dialup Technology: 문서를 참조하십시오.개요 및 설명.

예: 2:

*Mar  1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing uninteresting (no dialer-group defined).

다이얼러 인터페이스에 구성된 다이얼러 그룹이 없습니다.다음 예와 같이 다이얼러 그룹을 추가합니다.

 interface Dialer1
  dialer-group X

참고:X의 값은 dialer-list 명령과 함께 사용되는 값과 같아야 합니다.

예: 3:

*Mar  1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing uninteresting (dialer-list 1 not defined).

다이얼러 인터페이스에 다이얼러 그룹 문이 있지만 참조되는 다이얼러 목록이 없습니다.다음 예와 같이 다이얼러 목록을 구성합니다.

dialer-list X protocol ip permit

참고:X의 값은 다이얼러 인터페이스에서 dialer-group 명령과 함께 사용되는 값과 같아야 합니다.

예 4

*Mar  1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing interesting (ip PERMIT)
*Mar  1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.

이 경우 발신 패킷은 링크를 불러오기에 충분히 흥미로운 것으로 간주되지만 전화를 걸 수 있는 물리적 인터페이스가 없습니다.다이얼러 풀 멤버 X가 물리적 인터페이스에 구성되고 다이얼러 풀 X가 다이얼러 인터페이스에 구성되었는지 확인합니다.예:

interface BRI0
 dialer pool-member 1
!
interface Dialer1
 dialer pool 1

또한 BRI 인터페이스가 종료 상태가 아닌지 확인합니다.

예 5

*Mar  1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing interesting (ip PERMIT)
*Mar  1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.

이 경우 다이얼러 인터페이스에 다이얼러 문자열이 구성되지 않습니다.라우터가 전화를 걸려고 하지만 호출할 ISDN 디렉터리 번호를 알지 못합니다.다이얼 문자열 정의:

interface Dialer1
 dialer string 8134

자세한 문제 해결 정보는 debug isdn q931 명령을 사용하여 ISDN BRI Layer 3 문제 해결 문서의 "The Calling Router does not send a SETUP Message" 섹션을 참조하십시오.

문제 해결 순서도로 돌아가기

문제 해결:ISDN Call Connect가 성공적으로 작동합니까?

ISDN 호출 연결 여부를 식별하려면 디버그에서 CONNECT_ACK 및 %LINK-3-UPDOWN 메시지를 찾습니다.

*Mar  1 00:06:36.743: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x02
*Mar  1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

이 메시지가 표시되면 ISDN 통화가 성공적으로 연결되었으며 다음 단계로 진행할 수 있습니다.이와 같은 메시지가 표시되지 않을 경우 아래의 가능한 원인을 확인하십시오.

문제 해결 순서도로 돌아가기

증상:ISDN 통화가 연결되지 않음

  1. 다음과 유사한 출력이 표시되면 ISDN 케이블이 라우터와 텔코 잭에 모두 연결되어 있는지 확인합니다. 
    *Mar  1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4),
100 bytes, outgoing interesting (ip PERMIT)
*Mar  1 21:31:18.190: BR0 DDR: rotor dialout [priority]
*Mar  1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4)
*Mar  1 21:31:18.198: BR0 DDR: Attempting to dial 8134.
*Mar  1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4),
100 bytes, outgoing interesting (ip PERMIT).

*Mar  1 21:31:26.226: ISDN BR0: Could not bring up interface
*Mar  1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E
*Mar  1 21:31:26.246: ISDN BR0: Could not bring up interface.
Success rate is 0 percent (0/5)
  2. ISDN 회로가 제대로 작동하는지 확인합니다.show isdn status 명령을 사용하여 레이어 1이 ACTIVE, 레이어 2가 MULTIPLE_FRAME_ESTABLISHED이고 SPID(필요한 경우)가 유효한지 확인합니다.자세한 내용은 BRI 문제 해결을 위해 show isdn status 명령 사용 문서를 참조하십시오.

    Cisco 디바이스에서 show isdn status 명령의 출력이 있는 경우 Cisco CLI Analyzer를 사용하여 잠재적인 문제 및 수정 사항을 표시할 수 있습니다.Cisco CLI Analyzer를 사용하려면 등록된 사용자여야 하며 로그인되어 JavaScript가 활성화되어 있어야 합니다.

  3. 구성된 ISDN 다이얼러 문자열이 올바른지 확인합니다.PBX를 통해 연결된 경우 외부 회선을 받으려면 앞에 0을, 9자리 또는 그 밖의 숫자를 추가해야 할 수도 있습니다.

  4. 연결에서 장거리 통신사를 사용하는 경우 로컬 통신사와 장거리 통신 사업자에게 연락하여 서비스가 활성화되었는지 확인합니다.로컬 Telco에는 아웃바운드 ISDN 장거리 통화가 적절한 장거리 통신 사업자 네트워크로 전환되지 않도록 잘못 구성된 ISDN 회로가 있는 경우가 많습니다.또한 장거리 공급자 네트워크가 작동하는지 확인해야 합니다.

    미국에서는 Telco 또는 장거리 공급자가 문제를 해결할 수 없는 상황에서 사전 가입한 PIC(Interexchange Carrier)를 사용할 수 있습니다.PIC 코드는 LEC(Local Exchange Carriers)에 대한 미국 장거리 통신 사업자를 식별하는 7자리 접두사입니다. 이를 통해 고객은 개별 통화에 서로 다른 장거리 통신사를 사용할 수 있습니다.PIC 코드는 전화를 건 번호에 대한 접두사로 구성됩니다.대부분의 PIC는 1010xxx 형식입니다.

    다이얼러 문자열 xxxxx 또는 다이얼러 맵 없음을 사용하여 기존 번호를 제거한 다음 새 번호를 구성합니다.

    예를 들어, 다이얼러 문자열 10103215125551111입니다.

  5. ISDN 연결 끊기 메시지를 찾습니다.

    Cisco IOS® 소프트웨어는 이 연결 끊기 메시지에서 원인 코드를 디코딩하며 문제의 원인을 규명하는 유용한 정보를 자주 포함하는 명확한 텍스트 메시지를 제공합니다.여기에서 찾을 수 있는 문자열은 다음과 같습니다.

    • 할당되지 않았거나 할당되지 않은 번호
    • 호환되지 않는 대상(둘 다 전화를 건 번호가 잘못되었을 수 있음을 나타남)
    • 통화 중 수(호출된 쪽이 사용 중임을 나타냅니다.)
    • 일시적인 장애(Telco 네트워크의 일시적인 중단 표시)

    특정 연결 끊김 원인에 대한 가능한 원인을 찾으려면 디버그 isdn q931 연결 끊기 원인 코드 이해를 참조하십시오.

    예를 들어 잘못된 ISDN 번호로 인한 연결 끊기는 다음과 같이 표시될 수 있습니다.

    *Mar  3 00:10:38.756: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0xEB
*Mar  3 00:10:38.764:         Cause i = 0x84D8 - Incompatible destination

    이전에 참조한 Disconnect Cause Codes 문서를 참조하여 연결 끊기 코드가 ISDN이 아닌 장비(예: 아날로그 회선)에 연결하려고 시도했을 때 발생했는지 확인할 수 있습니다.

    잘못된 형식의 번호로 인한 연결 끊기는 다음과 같이 표시될 수 있습니다.

    Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
    Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format
(incomplete number)

    디버그 isdn q931 연결 끊기 원인 코드 이해 문서를 참조하여 연결 끊기 코드가 원격 ISDN 번호에 대한 잘못된 형식 때문에 발생했는지 확인할 수 있습니다.목적지 주소가 인식할 수 없는 형식으로 표시되거나 목적지 주소가 완전하지 않아 연결이 실패합니다.

    다음 예에서는 잘못된 ISDN 번호로 인해 거부된 통화를 보여줍니다.

    *Mar 13 11:29:04.758: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x83
*Mar 13 11:29:04.769:         Cause i = 0x8295 - Call rejected


  6. Telco에서 사용할 서비스 프로필 식별자(SPID)를 제공한 경우, 이러한 SPID가 BRI 인터페이스에 구성되어 있는지 확인하십시오.SPID는 일반적으로 미국 및 NI 및 DMS 스위치 유형에서만 사용됩니다(5ess switchtype은 SPID가 필요하지 않음). 
    interface BRI0
 isdn spid1 51255511110101 5551111
 isdn spid2 51255511120101 5551112

    show isdn status 명령을 사용하여 SPID가 올바른지 확인할 수 있습니다.

    자세한 내용은 ISDN BRI SPID 문제 해결 문서를 참조하십시오.

    Cisco 디바이스에서 show isdn status 명령의 출력이 있는 경우 Cisco CLI Analyzer를 사용하여 잠재적인 문제 및 수정 사항을 표시할 수 있습니다.Cisco CLI Analyzer를 사용하려면 등록된 사용자여야 하며 로그인되어 JavaScript가 활성화되어 있어야 합니다.

  7. 위 절차에서 문제를 해결하지 못한 경우 추가 문제 해결을 위해 debug isdn q931 명령을 사용하여 ISDN BRI Layer 3 문제 해결 문서를 사용합니다.

문제 해결 순서도로 돌아가기

문제 해결:PPP LCP 단계가 성공합니까?

디버그 출력에서 다음에 대한 메시지 줄을 확인해야 합니다.

*Mar  1 00:06:36.887: BR0:1 LCP: State is Open

이 행이 표시되면 LCP(Link Control Protocol)가 성공적으로 협상되었음을 나타냅니다.열려 있지 않은 상태는 LCP가 실패했음을 나타냅니다.

문제 해결 순서도로 돌아가기

증상:PPP LCP 단계가 성공하지 못함

가능한 원인:PPP가 구성되지 않음

다음 행과 유사한 디버그 출력이 있는 경우 PPP가 시작되지 않았음을 나타냅니다.

*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up.
*Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT).
*Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT).
*Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT)
*Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now
connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets
*Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT).
Success rate is 0 percent (0/5)

디버그 출력에서 라우터가 PPP CONFREQ 메시지를 전송하지 않는다는 점에 유의하십시오.이는 인터페이스가 PPP 캡슐화를 위해 구성되지 않았기 때문일 수 있습니다.

이 경우 다이얼러 인터페이스 및 물리적 인터페이스 아래에서 캡슐화 ppp 명령을 구성했는지 확인합니다.다음은 예입니다.

interface Dialer1
 encapsulation ppp
or

interface BRI 0
 encapsulation ppp

가능한 원인:ISDN 속도 불일치

아웃바운드 LCP CONFREQ 메시지만 볼 수 있지만 인바운드 LCP 메시지는 표시되지 않는 경우도 있습니다.다음은 예입니다.

*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open
[0 sess, 0 load]
! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP:    MagicNumber 0x545D708A (0x0506545D708A).
! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent
! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP:    MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP:    MagicNumber 0x545D708A (0x0506545D708A)

이 문제는 다음과 같은 원인으로 인해 발생할 수 있습니다.

  • PPP에 대해 원격 끝이 구성되지 않았습니다.원격 엔드에서 명령 캡슐화 ppp를 구성합니다.
  • 전송 미디어를 통과하지 못하는 패킷입니다.가장 일반적인 원인은 ISDN 속도 불일치

ISDN의 관점에서 문제의 본질은 한 쪽이 56k로 연결되고 다른 쪽은 64k로 연결된다는 것입니다.로컬 또는 원격 회로가 기본 64K 연결을 지원하지 않을 수 있습니다.양쪽 끝을 56k에서 실행되도록 구성하십시오.

다이얼러 프로파일의 경우:

maui-soho-01(config)#interface Dialer1
maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below)
maui-soho-01(config-if)#exit
maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string 
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)

레거시 DDR(다이얼러 맵):

maui-soho-01(config)#interface bri 0
maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560 
!-- The keyword speed 56 sets the outgoing call rate at 56k

가능한 원인:두 라우터가 사용할 인증 프로토콜(CHAP 또는 PAP)에 동의하지 않음

다음 행과 유사한 디버그 출력이 있는 경우 이는 라우터와 원격 측에서 사용할 인증 프로토콜에 동의하지 않았음을 나타냅니다.

*Mar  1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14
*Mar  1 00:07:24.055: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:07:24.059: BR0:1 LCP:    MagicNumber 0x1110C3C5 (0x05061110C3C5)
! -- An incoming CONFREQ (Config-Request) indicating the peer is 
! -- willing to do PAP
*Mar  1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9
*Mar  1 00:07:24.063: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP 
! -- The router suggests CHAP instead
*Mar  1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14
*Mar  1 00:07:24.091: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:07:24.091: BR0:1 LCP:    MagicNumber 0x1110C3C5 (0x05061110C3C5)
! -- The peer once again requests PAP 
! -- This is probably because PAP is the only protocol configured on the peer 
! -- The router will once again CONFNAK PAP and suggest CHAP
*Mar  1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9
*Mar  1 00:07:24.099: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
! -- The router NAKs PAP and suggests CHAP for the 2nd time
*Mar  1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4
*Mar  1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4
! -- The two routers cannot agree on LCP parameters so the call is disconnected

이 경우 다음을 구성했는지 확인합니다.

interface Dialer1
 encapsulation ppp
 ppp authentication chap pap callin
 ! -- This permits both CHAP and PAP and one-way authentication

CHAP(Challenge Handshake Authentication Protocol) 또는 PAP(Password Authentication Protocol)에 대한 자세한 내용은 다음 문서를 참조하십시오.

추가 PPP 문제 해결을 위해 Cisco Support Community를 사용할 수도 있습니다.

문제 해결 순서도로 돌아가기

문제 해결:PPP 인증이 성공합니까?

다음과 유사한 행에 대한 디버그 출력을 확인합니다.

*Mar  1 00:06:36.943: BR0:1 PPP: Phase is UP

문제 해결 순서도로 돌아가기

증상:PPP 인증 실패

다음 행을 구성했는지 확인합니다.

interface Dialer1
 ppp chap hostname XXXXX
 ppp chap password YYYYY
 ppp pap sent-username XXXXX password YYYYY

이 예에서 XXXXX는 사용자 이름이고 YYYYY는 사용자 암호입니다.

참고:사용자 및 피어가 사용하는 인증 방법에 대한 사용자 이름과 비밀번호만 구성합니다.예를 들어, 둘 다 PAP를 사용하지 않을 경우 ppp pap sent-username 명령이 필요하지 않습니다.그러나 피어가 PAP를 지원하는지 CHAP를 지원하는지 확실하지 않은 경우 둘 다 구성합니다.

Cisco IOS 소프트웨어 버전 및 컨피그레이션에 따라 비밀번호가 컨피그레이션에 암호화되어 표시될 수 있습니다.이 경우 show running-configuration 명령을 수행할 때 다음 예와 같이 단어 "password" 뒤에 숫자 7과 숫자 시퀀스가 오는 것을 볼 수 있습니다.

interface Dialer1
 ppp chap password 7 140005

이 경우, 구성된 비밀번호가 정확한지 여부를 확인하려면 컨피그레이션을 확인하십시오.암호가 올바른지 확인하려면 구성 모드를 시작하고 비밀번호를 다시 한 번 제거하고 구성하면 됩니다.디버그에서 비밀번호 오류를 식별하려면 디버그 출력을 아래의 샘플 출력과 비교합니다.

이 라우터가 피어를 인증할 경우 명령 사용자 이름 사용자 이름 사용자 이름 비밀번호를 구성해야 합니다. 여기서 username은 인증을 위해 피어 라우터에서 제공하는 이름입니다.

예 1

아래 메시지와 같은 메시지는 CHAP 암호가 올바르지 않음을 의미합니다.

*Mar  1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP"
! -- Incoming CHAP challenge
*Mar  1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX
 ! -- Using alternate hostname configured with ppp chap hostname command 
*Mar  1 00:16:54.411: BR0:1 CHAP: Username ISP not found
*Mar  1 00:16:54.415: BR0:1 CHAP: Using default password
! -- Using password configured with ppp chap password command
*Mar  1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX"
! -- Sending response from "XXXXX" which is the alternate hostname for the router
*Mar  1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is
"MD/DES compare failed"
! -- Incoming CHAP failure. The remote router failed to authenticate this router.
! -- Check the username and password configured on both routers
*Mar  1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4
*Mar  1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4

팁:수신 CHAP 오류(CHAP로 표시됨:I FAILURE)는 피어가 라우터를 인증할 수 없음을 의미합니다.피어 라우터에서 debug ppp 협상을 사용하여 정확한 실패 원인을 확인합니다.

자세한 내용은 ppp chap 호스트 이름을 사용하는 PPP 인증 및 ppp 인증 chap 호출 명령을 참조하십시오.

예: 2:

아래 메시지와 같은 메시지는 CHAP 사용자 이름이 유효하지 않음을 의미할 수 있습니다.

*Mar  1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP"
! -- Incoming CHAP challenge
*Mar  1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw
 ! -- Using alternate hostname configured with ppp chap hostname command 
*Mar  1 00:18:34.839: BR0:1 CHAP: Username ISP not found
*Mar  1 00:18:34.839: BR0:1 CHAP: Using default password
! -- Using password configured with ppp chap password command
*Mar  1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw"
! -- Sending response from "Xdwqdqw" which is the alternate hostname 
! -- for the router
*Mar  1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26
msg is "Authentication failure"
! -- Incoming CHAP failure. The remote router failed to authenticate 
! -- this router. Check the username and password configured on both routers
*Mar  1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4
*Mar  1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4

팁:수신 CHAP 오류(CHAP로 표시됨:I FAILURE)는 피어가 라우터를 인증할 수 없음을 의미합니다.피어 라우터에서 debug ppp 협상을 사용하여 정확한 실패 원인을 확인합니다.

자세한 내용은 ppp chap 호스트 이름을 사용하여 PPP 인증 문서 및 ppp 인증 chap 호출 명령을 참조하십시오.

예: 3:

아래와 같은 메시지는 PAP 비밀번호가 유효하지 않음을 의미합니다.

*Mar  1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX"
! -- Outgoing PAP Authentication Request from XXXXX 
! -- XXXXX is the username configured in  
! -- ppp pap sent-username XXXXX password YYYYY
*Mar  1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is
"Authentication failure"
! -- An incoming PAP failure. The peer could not authenticate this router 
! -- Verify that the username and password configured on both routers 
! -- are identical
*Mar  1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4
*Mar  1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4
*Mar  1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING

자세한 내용은 PPP PAP(Configuring and Troubleshooting PPP Password Authentication Protocol) 문서를 참조하십시오.

예 4

아래와 같은 메시지는 PAP 사용자 이름이 유효하지 않음을 의미합니다.

*Mar  1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer
*Mar  1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew"
! -- Outgoing PAP Authentication Request from ewddew 
! -- ewddew is the username configured in  
! -- ppp pap sent-username ewddew password YYYYY
*Mar  1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27
msg is "Authentication failure"
! -- An incoming PAP failure. The remote router could not authenticate 
! -- this router. Check the username and password configured on both routers 
! -- Note the PAP authentication failure in example 3 and 4 are identical. 
! -- Hence the only way to determine if the username, password or both are 
! -- wrong is to run debug ppp negotiation on the authenticating router
*Mar  1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4
*Mar  1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4
*Mar  1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING

자세한 내용은 PPP PAP(Configuring and Troubleshooting PPP Password Authentication Protocol) 문서를 참조하십시오.

또한 Cisco Support Community를 사용하여 추가 PPP 트러블슈팅을 수행할 수 있습니다.

문제 해결 순서도로 돌아가기

문제 해결:PPP NCP(IPCP) 단계가 완료됩니까?

IPCP에서 협상된 키 요소는 각 피어의 주소입니다.IPCP 협상 전에 각 피어는 두 가지 가능한 상태 중 하나에 속합니다.IP 주소가 있거나 없는 경우피어에 이미 주소가 있는 경우 CONFREQ의 해당 주소를 다른 피어로 전송합니다.다른 피어에서 주소를 사용할 수 있으면 CONFACK가 반환됩니다.주소가 허용되지 않으면 회신은 피어가 사용할 주소를 포함하는 CONNAK입니다.

이 단계에서는 단 한 개의 회선을 통해 제대로 식별할 수 없습니다.IPCP(IP Control Protocol)가 제대로 작동하려면 IP 주소가 양방향으로 협상되었는지 확인해야 합니다.다음 행에 대한 디버그를 확인하십시오.

*Mar  1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10
*Mar  1 00:06:36.971: BR0:1 IPCP:    Address 194.183.201.1(0x0306C2B7C901)

및

*Mar  1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.015: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)

및

*Mar  1 00:06:37.015: BR0:1 IPCP: State is Open

이 세 줄 집합은 즉시 서로 이어지지 않을 수 있습니다.다른 옵션 중에서 그 아래에 주소가 있는 발신 Configure Acknowledge(O CONFACK)가 있는지 확인하는 것이 중요합니다.

또한 아래에 다른 IP 주소가 있는 수신 구성 승인(I CONFACK)이 있어야 합니다.

마지막으로, IPCP 상태가 열려 있음을 나타내는 행이 있어야 합니다.그런 다음 라우터에서 두 IP 주소를 직접 ping할 수 있어야 합니다.

문제 해결 순서도로 돌아가기

증상:PPP NCP(IPCP) 협상이 성공하지 못함

문제/장애:IP 주소 협상 실패

IPCP가 실패할 수 있는 이유 중 하나는 IP 주소 협상 실패 때문입니다.예를 들어, 클라이언트 라우터에 다른 IP 주소가 구성된 반면 NAS는 클라이언트에 주소를 할당하려고 할 수 있습니다. 또 다른 일반적인 문제는 클라이언트가 주소를 요청하고 NAS에 클라이언트에 사용 가능한 주소가 없는 경우입니다.

발신 라우터에서:

호출된 라우터가 발신 라우터에 동적으로 IP 주소를 할당하는 경우 다이얼러 인터페이스에서 협상된 명령 ip 주소가 있는지 확인합니다.

NAS Provider/ISP에서 고정 IP 주소를 제공한 경우 이 IP 주소(및 서브넷 마스크)가 명령 ip 주소 subnet_mask를 사용하여 다이얼러 인터페이스에 구성되었는지 확인합니다.

호출된 라우터에서:

연결을 제어하는 인터페이스(예: int Dialer x)에 IP 주소가 있으며 peer default ip address address 명령을 사용하여 피어에 주소를 할당하는지 확인합니다.

참고:클라이언트 라우터에 IP 주소가 구성된 경우 peer default ip address 명령을 사용하여 주소를 할당할 필요가 없습니다.

자세한 내용은 문서 전화 접속 기술:트러블슈팅 기법.

문제/장애:호출된 라우터가 다이얼러 프로파일 바인딩에 실패함

인증된 사용자 이름이 다이얼러 인터페이스에 구성된 다이얼러 원격 이름과 일치하지 않으면 호출된 라우터에서 통화가 끊어집니다.다음은 이러한 오류에 대한 샘플 디버그 다이얼러 출력입니다.

발신 라우터에서:

다음 디버그는 호출된 라우터에서 잘못된 다이얼러 프로필 바인딩으로 인한 연결 끊기를 보여줍니다.

*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4
! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0xA0
*Mar 15 03:19:13.226:         Cause i = 0x8090 - Normal call clearing
! -- We have received (RX) a DISCONNECT from the peer 
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX ->  RELEASE pd = 8  callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call

참고:호출된 측의 디버그는 피어가 통화를 끊었음을 나타내는 경우를 제외하고 이 문제를 해결하는 데 도움이 되지 않습니다.문제 해결을 호출된 라우터로 이동합니다.

호출된 라우터에서:

다음 디버그는 다이얼러 프로필 바인딩 문제로 인해 실패한 통화를 보여줍니다.

*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR:
Authenticated host maui-soho-03 with no matching dialer profile
! -- a binding failure because the dialer remote-name 
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]

해결책:

다이얼러 인터페이스에서 다이얼러 풀 번호 명령을 구성합니다.풀 번호는 물리적 인터페이스에 구성된 풀 번호와 일치해야 합니다.

다이얼러 인터페이스에서 dialer remote-name 명령을 구성합니다.지정된 이름은 인증을 위해 원격 라우터에서 제공한 사용자 이름과 정확히 일치해야 합니다.이 예에서 인증된 사용자 이름은 maui-soho-03입니다.

바인딩 문제에 대한 자세한 문제 해결 정보는 다이얼러 프로파일 구성 및 문제 해결 문서를 참조하십시오.

추가 PPP 문제 해결을 위해 Cisco Support Community를 사용할 수도 있습니다.

문제 해결 순서도로 돌아가기

연결 후 문제

증상:통화 연결이 중간에 끊기거나 통화 연결이 끊어지지 않음

통화가 예기치 않게 연결이 끊어지거나 통화가 연결 해제되지 않는 경우 다이얼러 유휴 시간 제한 및 흥미로운 트래픽 정의를 확인합니다.특정 패킷이 관심 있는지 여부를 확인하려면 debug dialer packet 명령을 사용할 수 있습니다.예:

Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, 
outgoing uninteresting (list 101)
Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes,
outgoing interesting (list 101)

위의 예에서 OSPF Hello는 액세스 목록 101당 흥미롭지 않지만 두 번째 패킷은 액세스 목록 101당 흥미롭습니다.

  1. 다이얼러 인터페이스 컨피그레이션에서 다이얼러 idle-timeout을 조정합니다.기본값은 120초이지만 필요에 따라 이 값을 높이거나 낮출 수 있습니다.
  2. 흥미로운 트래픽 정의를 변경합니다(dialer-list 명령으로 구성). 통화 연결이 중간에 끊어질 경우 흥미로운 트래픽을 더 느슨하게 정의할 수 있습니다.통화 연결이 끊어지지 않으면 흥미로운 트래픽 정의가 더 제한적으로 변경됩니다.예를 들어 라우팅 프로토콜 트래픽을 재미없는 것으로 정의할 수 있습니다.다음은 흥미로운 트래픽 정의 샘플입니다. 
    access-list 101 remark Interesting traffic for dialer-list 1
access-list 101 deny ospf any any
    !--- mark OSPF as uninteresting
    !--- This will prevent OSPF hellos from keeping the link up.
    access-list 101 deny udp any any eq ntp
! -- Define ntp traffic as NOT interesting.
    ! -- This will prevent periodic ntp traffic from keeping 
    ! -- the link up indefinitely.
    access-list 101 permit ip any any
    ! -- All other IP traffic is interesting.
    ! -- Change this depending on your traffic needs.
    dialer-list 1 protocol ip list 101
! -- this interesting traffic is applied to the dialer 
    ! -- interface using dialer-group 1

    자세한 내용은 문서 전화 접속 기술:개요 및 설명.

증상:라우터가 주기적으로 연결 다이얼링

어떤 경우에는 링크가 작동해야 하는 명백한 사용자 트래픽이 없더라도 라우터가 주기적으로 연결을 다이얼하는 것을 확인할 수 있습니다.이로 인해 ISDN 서비스가 분당 청구되는 요금이 많이 발생할 수 있습니다.

가장 일반적인 원인은 라우팅 프로토콜, ntp, snmp 등 주기적 트래픽을 생성하는 프로세스가 실수로 흥미롭게 지정되었을 수 있다는 것입니다.이 문제를 해결하는 것은 2단계 문제입니다.

  1. 링크를 다이얼하는 트래픽을 식별합니다.
  2. 해당 트래픽을 재미없는 트래픽으로 지정합니다.

링크를 다이얼로 만드는 트래픽을 식별합니다.

링크가 다이얼하는 트래픽을 식별하려면 디버그 다이얼러 패킷을 활성화해야 합니다.ISDN 링크가 다운된 동안 라우터를 모니터링하고 링크를 불러오려고 시도하는 주기적인 흥미로운 트래픽을 확인합니다.

팁:특별히 필요하지 않은 경우, 라우터에 구성된 모든 라우팅 프로토콜을 관심 없는 것으로 지정합니다.

다음 예에서는 주기적인 OSPF Hello가 흥미롭게 표시된 것을 보여줍니다.

*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5),
  64 bytes, outgoing interesting (ip PERMIT)

위 패킷이 OSPF hello임을 식별하는 유일한 방법은 OSPF에 대해 정의된 목적지 주소(d=224.0.0.5)에서 오는 것입니다.다음 표에는 일부 공통 라우팅 프로토콜에 사용되는 주소가 나열되어 있습니다.

라우팅 프로토콜
주기적 대상 주소
업데이트 또는 keepalive
RIPv1
255.255.255.255
RIPv2
224.0.0.9
EIGRP
224.0.0.10
OSPF
224.0.0.5

라우터가 다이얼하는 트래픽(라우팅 프로토콜 또는 기타 주기적 트래픽)은 흥미없는 것으로 표시되어야 합니다.

주기적 트래픽을 재미없는 트래픽으로 지정

흥미로운 트래픽 정의를 변경합니다(dialer-list 명령으로 구성). 이 예에서는 OSPF 및 NTP 트래픽을 재미없는 것으로 정의합니다.다음은 흥미로운 트래픽 정의 샘플입니다.

access-list 101 remark Interesting traffic for dialer-list 1
access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp
! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping 
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101
! -- this interesting traffic is applied to the dialer interface 
! -- using dialer-group 1

자세한 내용은 문서 전화 접속 기술:개요 및 설명.

참고:OSPF에는 디맨드 회로라는 기능이 있으며 여기에서 사용할 수도 있습니다.자세한 내용은 Why OSPF Demand Circuit Keep Up the Link(OSPF Demand Circuit가 링크를 계속 가동하는 이유) 문서를 참조하십시오.

증상:두 번째 B 채널이 연결되지 않음

대부분의 경우 라우터는 하나의 B 채널에서만 연결할 수 있으며 다른 B 채널은 유휴 상태로 유지됩니다.이 문제 해결에 대한 자세한 내용은 ISDN BRI 링크에서 두 번째 B-채널 통화 실패 문제 해결 문서를 참조하십시오.

IP 연결 문제

ISDN 링크가 나타나지만 링크를 통해 트래픽을 전달할 수 없는 경우 라우팅 또는 NAT 관련 문제일 수 있습니다.자세한 문제 해결 정보는 Cisco 지원 커뮤니티를 참조하십시오.

ISDN 링크를 WAN 연결에 대한 백업으로 사용하는 경우 DDR 백업 구성 및 문제 해결 문서를 참조하십시오.

관련 정보

TAC Authored

Cisco 엔지니어가 작성

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

Feedback피드백

지원 문의

이 문서가 적용되는 제품