다이얼 기술 연결 문제 해결 - IOS DDR에서 통화 시작

소개

이 문서에서는 서로 다른 유형의 전화 접속 연결을 트러블슈팅하는 방법을 제공하며 처음부터 끝까지 읽기 위한 것은 아닙니다.이 구조는 독자가 관심 영역으로 건너뛸 수 있도록 설계되어 있으며, 각각은 특정 케이스의 전체 문제 해결 테마에 따라 달라집니다.

사전 요구 사항

요구 사항

이 문서는 세 가지 주요 시나리오를 다룹니다.트러블슈팅을 시작하기 전에 어떤 유형의 통화를 시도하는지 확인한 다음 해당 섹션으로 이동하십시오.

• 캘린

• Cisco IOS DDR(Dial-on-Demand Routing)

• 비 DDR 콜아웃

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

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

기록

다이얼업은 단순히 최종 사용자를 대신하여 데이터를 전달하는 PSTN(Public Switched Telephone Network)을 적용하는 것입니다.CPE(Customer Premises Equipment) 디바이스가 전화 스위치에 연결을 연결할 전화 번호를 전송합니다.AS3600, AS5200, AS5300 및 AS5800은 모두 디지털 모뎀 뱅크와 함께 PRI(Primary Rate Interface)를 실행할 수 있는 라우터의 예입니다.반면 AS2511은 외부 모뎀과 통신하는 라우터의 예입니다.

캐리어 시장은 크게 성장했고, 현재 시장에는 더 높은 모뎀 밀도를 요구하고 있다.이에 대한 해답은 전화 회사 장비와 디지털 모뎀의 개발 사이의 상호 작용이 더 높다는 것입니다.이 모뎀은 PSTN에 대한 직접 디지털 액세스를 지원합니다.그 결과, 디지털 모뎀이 즐기는 명확한 신호를 이용할 수 있는 고속 CPE 모뎀이 개발되었습니다.PRI 또는 BRI(Basic Rate Interface)를 통해 PSTN에 연결되는 디지털 모뎀이 V.90 통신 표준을 사용하여 53k 이상의 데이터를 전송할 수 있다는 사실은 이 아이디어의 성공을 입증합니다.

첫 번째 액세스 서버는 AS2509 및 AS2511이었습니다. AS2509는 외부 모뎀을 사용하여 8개의 수신 연결을 지원할 수 있으며 AS2511은 16개를 지원할 수 있습니다. AS5200은 2개의 PRI로 도입되었으며 디지털 모뎀을 사용하여 48명의 사용자를 지원할 수 있으며 기술 분야에서 큰 도약을 이루었습니다.4와 8개의 PRI를 지원하는 AS5300으로 모뎀 집적도가 꾸준히 증가했습니다.마지막으로, AS5800은 수십 개의 수신 T1과 수백 개의 사용자 연결을 처리해야 하는 통신 사업자 클래스 설치 요구 사항을 충족하기 위해 도입되었습니다.

다이얼러 기술에 대한 역사적인 논의에서 몇 가지 오래된 기술이 언급되고 있다.56Kflex는 Rockwell에서 제안한 이전(V.90 이전) 56k 모뎀 표준입니다.Cisco는 내부 모뎀에서 56Kflex 표준 버전 1.1을 지원하지만 CPE 모뎀을 가능한 한 빨리 V.90으로 마이그레이션할 것을 권장합니다.AS5100은 Cisco와 모뎀 제조업체의 합작 사업이었다.AS5100은 쿼드 모뎀 카드를 사용하여 모뎀 밀도를 높일 수 있는 방법으로 만들어졌습니다.쿼드 모뎀 카드를 공유하는 백플레인에 삽입하는 카드로 구축된 AS2511s 그룹과 듀얼 T1 카드를 사용했습니다.

표기 규칙

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

Cisco IOS DDR에서 통화 시작

수신 통화에 대한 문제 해결 접근 방식이 맨 아래에서 시작되는 동안 아웃바운드 연결 문제 해결은 맨 위에서 시작됩니다.

이성의 일반적인 흐름은 다음과 같다.

1. DDR(Dial on Demand Routing)에서 통화를 시작합니까?(예 대답: 다음 질문으로 넘어갑니다.)

2. 비동기 모뎀인 경우 채팅 스크립트에서 필요한 명령을 실행합니까?

3. 통화가 PSTN에 전달됩니까?

4. 원격 엔드가 통화에 응답합니까?

5. 통화가 완료되었습니까?

6. 데이터가 링크를 통해 전달됩니까?

7. 세션이 설정되었습니까?(PPP 또는 터미널)

다이얼러가 원격 대상에 대한 호출을 시도하는지 확인하려면 디버그 다이얼러 이벤트 명령을 사용합니다.자세한 정보는 디버그 다이얼러 패킷에서 얻을 수 있지만 debug dialer packet 명령은 리소스를 많이 사용하므로 여러 다이얼러 인터페이스가 작동하는 사용 중인 시스템에서는 사용할 수 없습니다.

IP 패킷에 대한 다음 디버그 다이얼러 이벤트 출력 줄은 DDR 인터페이스의 이름과 패킷의 소스 및 목적지 주소를 나열합니다.

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

트래픽이 다이얼 시도를 시작하지 않을 경우 가장 일반적인 이유는 잘못된 컨피그레이션(흥미로운 트래픽 정의, 다이얼러 인터페이스의 상태 또는 라우팅)입니다.

전화 걸기

라우팅 및 흥미로운 트래픽 필터가 올바른 경우 통화를 시작해야 합니다.이는 디버그 다이얼러 이벤트를 사용하여 확인할 수 있습니다.

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

다이얼링 원인이 확인되었지만 다이얼을 시도하지 않은 경우 일반적으로 다이얼러 맵 또는 다이얼러 프로파일이 잘못 구성되어 있습니다.

Dialer1: Can't place call, no dialer pool set

다음으로, 사용 중인 미디어 유형을 식별합니다.

• 외부 비동기 모뎀 DDR

• CAS(Channel Associated Signaling) T1/E1 비동기 모뎀 DDR

• PRI 비동기 모뎀 DDR

• BRI 비동기 모뎀 DDR

• PRI ISDN DDR

• BRI ISDN DDR

외부 비동기 모뎀 DDR

1. 외부 비동기 모뎀 DDR을 식별하려면 다음 명령을 사용한 다음 전화를 시도합니다.

   router# debug modem
   router# debug chat line  
            
   
   

2. 모뎀 통화의 경우 통화를 계속하려면 채팅 스크립트를 실행해야 합니다.다이얼러 맵 기반 DDR의 경우 다이얼러 맵 명령의 modem-script 매개 변수에 의해 채팅 스크립트가 호출됩니다.DDR이 다이얼러 프로파일 기반인 경우 TTY 라인에 구성된 명령 스크립트 다이얼러가 이를 수행합니다.두 방법 모두 라우터의 전역 컨피그레이션에 존재하는 채팅 스크립트를 사용합니다. 예를 들면 다음과 같습니다.

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   어느 경우든 채팅 스크립트 활동을 보는 명령은 디버그 채팅입니다.다이얼러 맵 또는 다이얼러 문자열 명령에 사용된 다이얼 문자열(즉, 전화 번호)이 5551212이면 디버그 출력은 다음과 같습니다.

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 채팅 스크립트에서 "Sending string(전송 문자열)"을 기준으로 예상 통화(즉, 올바른 번호)를 시도하는지 확인합니다. 채팅 스크립트가 예상 통화를 시도하지 않는 경우 채팅 스크립트의 구성을 확인합니다.채팅 스크립트를 수동으로 시작하려면 exec 프롬프트에서 start-chat 명령을 사용합니다.

4. "시간 초과 예상:CONNECT"는 다음과 같은 여러 가지 가능성을 설명할 수 있습니다.

   • 가능성 1:로컬 모뎀이 실제로 전화를 걸고 있지 않습니다.모뎀에 대한 역방향 텔넷을 수행하고 수동으로 다이얼을 시작하여 모뎀을 호출할 수 있는지 확인합니다.원격 끝이 응답하지 않는 것처럼 보일 경우 ATDT <number> 명령을 사용하여 수동으로 로컬 번호를 호출하고 벨소리를 수신하여 원래 모뎀에서 전화를 걸었는지 확인합니다.

   • 가능성 2:원격 모뎀이 응답하지 않습니다.일반 POTS 전화로 원격 모뎀에 전화를 걸어 테스트합니다.다음과 같이 하십시오.

     1. 전화 번호가 올바른지 확인합니다.핸드셋을 사용하여 수신 번호를 호출합니다.모뎀에서 사용하는 것과 동일한 케이블을 벽면에 사용해야 합니다.수동 통화가 수신 비동기 모뎀에 연결할 수 있으면 원래 모뎀이 제대로 작동하지 않을 수 있습니다.모뎀을 확인하고 필요에 따라 교체합니다.

     2. 수동 통화가 응답 비동기 모뎀에 연결할 수 없는 경우 수신 모뎀의 전화 케이블을 변경하고 수신 모뎀 회선에서 일반 전화기를 사용해 보십시오.일반 전화기로 전화를 받을 수 있는 경우 수신 모뎀에 문제가 있을 수 있습니다.

     3. 수동 통화가 여전히 해당 회선의 일반 전화기에 연결할 수 없는 경우 수신 시설에서 다른(정상) 회선을 시도합니다.연결이 정상인 경우, 수신 모뎀으로 가는 전화선을 텔코에서 확인하도록 합니다.

     4. 장거리 통화인 경우 원래 측에서 다른(정상) 장거리 번호를 시도하도록 합니다.이 경우 수신 시설 또는 회선이 장거리 통화를 수신하도록 프로비저닝되지 않을 수 있습니다.원래 회선이 다른 장거리 번호에 연결할 수 없는 경우 장거리 연결이 활성화되지 않았을 수 있습니다.다양한 장거리 회사에 1010 코드를 사용해 보십시오.

     5. 마지막으로 원래 회선에서 다른(정상 작동이 확인된) 현지 번호를 사용해 봅니다.연결이 여전히 실패하면 텔코가 원래 라인을 확인하도록 합니다.

   • 가능성 3:전화 건 번호가 잘못되었습니다.수동으로 다이얼하여 번호를 확인합니다.필요한 경우 컨피그레이션을 수정합니다.

   • 가능성 4:모뎀 교육에 시간이 너무 오래 걸리거나 TIMEOUT 값이 너무 낮습니다.chat-script 명령에서 TIMEOUT 값을 늘리십시오.TIMEOUT이 이미 60초 이상인 경우 모뎀과 연결된 DTE 사이에 케이블 문제가 있을 수 있습니다.교육 실패가 회선 문제 또는 모뎀 비호환성을 나타낼 수도 있습니다.

     개별 모뎀 문제의 맨 아래로 이동하려면 리버스 텔넷으로 원래 모뎀의 AT 프롬프트로 이동합니다.가능한 경우 수신 모뎀의 AT 프롬프트로도 이동합니다.대부분의 모뎀은 DTE 연결에 연결된 터미널 세션에 대한 링을 나타냅니다.ATM1을 사용하여 모뎀이 스피커로 소리를 보내 각 끝에 있는 사람들이 회선 상태를 들을 수 있도록 합니다.

     음악 소리가 나나요?만약 그렇다면, 회로를 청소하세요.비동기 모뎀이 작동하지 않을 경우 번호를 호출하고 정적인 소리를 듣습니다.기차 속도를 방해하는 다른 요인들이 있을 수 있다.텔넷을 비동기 모뎀으로 역수행하고 디버깅합니다.

5. 모든 것이 정상적으로 작동하고 CAS 비동기 모뎀 DDR에 연결할 수 없는 경우 PPP 디버깅을 시도하십시오.다음 명령을 사용합니다.

   router# debug ppp negotiation
        router# debug ppp authentication
   

   채팅 스크립트가 성공적으로 완료되면 모뎀이 연결됩니다.연결 문제 해결의 다음 단계에 대한 자세한 내용은 네트워크 문제 해결 가이드의 17장의 "Troubleshooting PPP" 섹션을 참조하십시오.

CAS T1/E1 비동기 모뎀 DDR

1. CAS T1/E1 async modem DDR을 식별하려면 다음 명령을 사용한 다음 전화를 시도합니다.

   경고:  사용 중인 시스템에서 디버그를 실행하면 CPU를 오버로드하거나 콘솔 버퍼를 오버런하여 라우터가 충돌할 수 있습니다.

   router# debug modem
   router# debug chat or debug chat line n
   
   router# debug modem csm
   router# debug cas
   

   참고: debug cas 명령은 Cisco IOS?소프트웨어 릴리스 12.0(7)T 이상이전 버전의 IOS에서는 명령 서비스 내부를 라우터 컨피그레이션의 기본 레벨에 입력해야 하며 modem-mgmt csm debug-rbs를 exec 프롬프트에 입력해야 합니다.Cisco AS5800에서 디버깅하려면 트렁크 카드에 연결해야 합니다.(디버그를 끄려면 modem-mgmt csm no-debug-rbs를 사용합니다.)

2. 모뎀 통화의 경우 통화를 계속하려면 채팅 스크립트를 실행해야 합니다.다이얼러 맵 기반 DDR의 경우 다이얼러 맵 명령의 modem-script 매개 변수에 의해 채팅 스크립트가 호출됩니다.DDR이 다이얼러 프로파일 기반인 경우 TTY 라인에 구성된 명령 스크립트 다이얼러가 이를 수행합니다.두 용도 모두 라우터의 전역 컨피그레이션에 존재하는 채팅 스크립트(예:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   어느 경우든 채팅 스크립트 활동을 보는 명령은 디버그 채팅입니다.다이얼러 맵 또는 다이얼러 문자열 명령에 사용된 다이얼 문자열(즉, 전화 번호)이 5551212이면 디버그 출력은 다음과 같습니다.

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 채팅 스크립트에서 "Sending string(전송 문자열)"을 기준으로 예상 통화(즉, 올바른 번호)를 시도하는지 확인합니다. 채팅 스크립트가 예상 통화를 시도하지 않는 경우 채팅 스크립트의 구성을 확인합니다.채팅 스크립트를 수동으로 시작하려면 exec 프롬프트에서 start-chat 명령을 사용합니다.

4. "시간 초과 예상:CONNECT"는 다음과 같은 여러 가지 가능성을 설명할 수 있습니다.

   • 가능성 1:로컬 모뎀이 실제로 전화를 걸고 있지 않습니다.모뎀에 대한 역방향 텔넷을 수행하고 수동으로 다이얼을 시작하여 모뎀에서 전화를 걸 수 있는지 확인합니다.원격 끝이 응답하지 않는 것처럼 보일 경우 ATDT<number> 명령을 사용하여 로컬 번호를 수동으로 호출하고 벨소리를 수신하여 모뎀에서 전화를 걸고 있는지 확인합니다.

     CAS T1 또는 E1을 통한 아웃바운드 통화 및 통합 디지털 모뎀의 경우 문제 해결 중 상당 부분이 다른 DDR 문제 해결과 유사합니다.PRI 회선을 통한 아웃바운드 통합 모뎀 통화도 마찬가지입니다.이러한 방식으로 통화를 하는 데 관련된 고유한 기능을 사용하려면 호출 실패 시 특별한 디버깅이 필요합니다.

     다른 DDR 상황의 경우 통화 시도가 요구되는지 확인해야 합니다.이 용도로 디버그 다이얼러 이벤트를 사용합니다.이 문서의 앞부분에서 IOS DDR을 참조하십시오.

     전화를 걸려면 먼저 통화에 모뎀을 할당해야 합니다.이 프로세스 및 후속 통화를 보려면 다음 debug 명령을 사용합니다.

     router# debug modem
     router# debug modem csm
     router# debug cas 
     

     참고: debug cas 명령은 AS5200 및 AS5300의 경우 먼저 IOS 버전 12.0(7)T에 나타나며, 이전 버전의 IOS에서는 exec 명령 modem-mgmt debug rbs와 함께 시스템 수준 구성 명령 서비스 내부를 사용합니다.

     디버깅 켜기:

     router#conf t 
     Enter configuration commands, one per line.  End with CNTL/Z. 
     router(config)#service internal 
     router(config)#^Z 
     router#modem-mgmt csm ? 
       debug-rbs     enable rbs debugging 
       no-debug-rbs  disable rbs debugging 
     router#modem-mgmt csm debug-rbs 
     router# 
     neat msg at slot 0: debug-rbs is on 
     neat msg at slot 0: special debug-rbs is on 
     

     디버그 끄기:

     router#modem-mgmt csm no-debug-rbs 
     neat msg at slot 0: debug-rbs is off 

     AS5800에서 이 정보를 디버깅하려면 트렁크 카드에 연결해야 합니다.다음은 FXS-Ground-Start에 대해 프로비저닝되고 구성된 CAS T1을 통한 일반적인 아웃바운드 통화의 예입니다.

     Mica Modem(1/0): Rcvd Dial String(5551111) 
     [Modem receives digits from chat script]
     
     CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_LOCK at slot 1 and port 0 
     
     CSM_PROC_OC4_DIALING: 
     CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
     
     Mica Modem(1/0): Configure(0x1) 
     
     Mica Modem(1/0): Configure(0x2) 
     
     Mica Modem(1/0): Configure(0x5) 
     
     Mica Modem(1/0): Call Setup 
     
     neat msg at slot 0: (0/2): Tx RING_GROUND 
     
     Mica Modem(1/0): State Transition to Call Setup 
     
     neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
     [Telco switch goes OFFHOOK]
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_START_TX_TONE at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 
     
     neat msg at slot 0: (0/2): 
     Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
     
     Mica Modem(1/0): Rcvd Tone detected(2) 
     
     Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
     
     Mica Modem(1/0): Rcvd Digits Generated 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_CONNECTED at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 
     
     Mica Modem(1/0): Link Initiate 
     
     Mica Modem(1/0): State Transition to Connect 
     
     Mica Modem(1/0): State Transition to Link 
     
     Mica Modem(1/0): State Transition to Trainup 
     
     Mica Modem(1/0): State Transition to EC Negotiating 
     
     Mica Modem(1/0): State Transition to Steady State 
     
     Mica Modem(1/0): State Transition to Steady State Speedshifting 
     
     Mica Modem(1/0): State Transition to Steady State
     

     다른 신호 유형이 있는 T1s 및 E1의 디버그는 유사합니다.

     디버깅에서 이 지점으로 이동하면 통화 및 응답 모뎀이 교육을 받고 연결되었으며 상위 계층 프로토콜이 협상을 시작할 수 있음을 나타냅니다.모뎀이 아웃바운드 통화에 올바르게 할당되었지만 연결이 이 정도까지 도달하지 못할 경우 T1을 검사해야 합니다.show controller t1/e1 명령을 사용하여 T1/E1이 작동하는지 확인합니다.show controller 출력에 대한 설명은 직렬 회선 문제 해결을 참조하십시오.T1/E1이 제대로 작동하지 않으면 T1/E1 문제가 필요합니다.

   • 가능성 2:원격 모뎀이 응답하지 않습니다.일반 전화로 원격 모뎀에 전화를 걸어 테스트합니다.다음과 같이 하십시오.

     1. 전화 번호가 올바른지 확인합니다.핸드셋을 사용하여 수신 번호를 호출합니다.

     2. 수동 통화가 응답 비동기 모뎀에 연결할 수 있는지 확인합니다.수동 통화가 응답 비동기 모뎀에 연결할 수 있는 경우 아웃바운드 음성 통화를 허용하도록 CAS 회선을 프로비저닝하지 못할 수 있습니다.

     3. 수동 통화가 응답 비동기 모뎀에 연결할 수 없는 경우 수신 모뎀의 전화 케이블을 변경하고 수신 모뎀 회선에서 일반 전화기를 사용해 보십시오.일반 전화기로 전화를 받을 수 있는 경우 수신 모뎀에 문제가 있을 수 있습니다.

     4. 수동 통화가 여전히 해당 회선의 일반 전화기에 연결할 수 없는 경우 수신 시설에서 다른(정상) 회선을 시도합니다.연결이 되면, 수신 모뎀으로 가는 전화선을 전화기에서 확인하도록 합니다.

     5. 장거리 통화인 경우 원래 측에서 다른(정상) 장거리 번호를 시도하도록 합니다.이렇게 하면 수신 시설 또는 회선이 장거리 통화를 수신하도록 프로비저닝되지 않을 수 있습니다.원래(CAS) 회선이 다른 장거리 번호에 연결할 수 없는 경우 장거리 연결이 활성화되지 않았을 수 있습니다.다양한 장거리 회사에 10-10번 코드를 사용해 보십시오.

     6. 마지막으로, 원래 CAS 라인에서 다른(정상 작동이 확인된) 로컬 번호를 사용해 보십시오.연결이 여전히 실패할 경우 텔코에서 CAS를 검사하도록 합니다.

   • 가능성 3:전화 건 번호가 잘못되었습니다.수동으로 다이얼하여 번호를 확인합니다.필요한 경우 컨피그레이션을 수정합니다.

   • 가능성 4:모뎀 교육에 시간이 너무 오래 걸리거나 TIMEOUT 값이 너무 낮습니다.chat-script 명령에서 TIMEOUT 값을 늘리십시오.TIMEOUT이 이미 60초 이상인 경우 모뎀과 연결된 DTE 사이에 케이블 문제가 있을 수 있습니다.교육 실패가 회선 문제 또는 모뎀 비호환성을 나타낼 수도 있습니다.

     개별 모뎀 문제의 맨 아래로 이동하려면 리버스 텔넷으로 원래 모뎀의 AT 프롬프트로 이동합니다.가능하면 역방향 텔넷을 사용하여 수신 모뎀의 AT 프롬프트에도 연결합니다.ATM1을 사용하여 모뎀이 스피커로 소리를 보내 각 끝에 있는 사람들이 회선 상태를 들을 수 있도록 합니다.

     음악 소리가 나나요?만약 그렇다면, 회로를 청소하세요.비동기 모뎀이 작동하지 않을 경우 번호를 호출하고 정적인 소리를 듣습니다.기차 속도를 방해하는 다른 요인들이 있을 수 있다.텔넷을 비동기 모뎀으로 역수행하고 디버깅합니다.

5. 모든 것이 정상적으로 작동하고 CAS 비동기 모뎀 DDR에 연결할 수 없는 경우 PPP 디버깅을 시도하십시오.채팅 스크립트가 성공적으로 완료되고 PPP 디버그에 오류가 있는 경우 Internetwork Troubleshooting Guide의 17장에서 "Troubleshooting PPP" 섹션을 참조하십시오.

PRI 비동기 모뎀 DDR

1. PRI 비동기 모뎀 DDR을 식별하려면 다음 명령을 사용한 다음 전화를 시도합니다.

   경고:  사용 중인 시스템에서 디버그를 실행하면 CPU를 오버로드하거나 콘솔 버퍼를 오버런하여 라우터가 충돌할 수 있습니다.

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug isdn
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. 모뎀 통화의 경우 통화를 계속하려면 채팅 스크립트를 실행해야 합니다.다이얼러 맵 기반 DDR의 경우 다이얼러 맵 명령의 modem-script 매개 변수에 의해 채팅 스크립트가 호출됩니다.DDR이 다이얼러 프로파일 기반인 경우 TTY 라인에 구성된 명령 스크립트 다이얼러가 이를 수행합니다.두 방법 모두 라우터의 전역 컨피그레이션에 존재하는 채팅 스크립트(예:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

   어느 경우든 채팅 스크립트 활동을 보는 명령은 디버그 채팅입니다.다이얼러 맵 또는 다이얼러 문자열 명령에 사용된 다이얼 문자열(전화 번호)이 5551212이면 디버그 출력은 다음과 같습니다.

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 채팅 스크립트에서 "Sending string(전송 문자열)"을 기준으로 예상 통화(올바른 번호)를 시도하는지 확인합니다. 채팅 스크립트가 예상 통화를 시도하지 않는 경우 채팅 스크립트의 구성을 확인합니다.채팅 스크립트를 수동으로 시작하려면 exec 프롬프트에서 start-chat 명령을 사용합니다.

4. "시간 초과 예상:CONNECT"는 다음과 같은 여러 가지 가능성을 설명할 수 있습니다.

   • 가능성 1:로컬 모뎀이 실제로 전화를 걸고 있지 않습니다.모뎀에 대한 역방향 텔넷을 수행하고 수동으로 다이얼을 시작하여 모뎀을 호출할 수 있는지 확인합니다.원격 끝이 응답하지 않는 것처럼 보일 경우 ATDT<number> 명령을 사용하여 수동으로 로컬 번호를 호출하고 벨소리를 수신하여 모뎀에서 전화를 걸고 있는지 확인합니다.통화가 나오지 않으면 ISDN 디버그를 켜십시오.BRI에서 ISDN 오류가 처음 의심되는 경우 항상 show isdn 상태의 출력을 확인합니다.주목해야 할 핵심 사항은 레이어 1은 활성 상태여야 하고 레이어 2는 MULTIPLE_FRAME_ESTABLISHED 상태여야 한다는 것입니다.이 출력을 읽는 방법과 해결 방법에 대한 자세한 내용은 Internetwork Troubleshooting Guide 16장, "Ingoating Show ISDN Status" 를 참조하십시오.

     아웃바운드 ISDN 통화의 경우 디버그 isdn q931 및 디버그 isdn 이벤트가 가장 사용하기 좋은 툴입니다.다행히 아웃바운드 통화 디버깅은 수신 통화 디버깅과 매우 유사합니다.정상적인 통화는 다음과 같습니다.

     *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
     

     CONNECT 메시지는 성공의 핵심 지표입니다.CONNECT가 수신되지 않은 경우 DISCONNECT 또는 RELEASE_COMP(릴리스 완료) 메시지 뒤에 원인 코드가 나타날 수 있습니다.

     *Mar 20 22:11:03.212: ISDN SE0:23: 
     RX <-RELEASE_COMP pd = 8 callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     원인 값은 다음 두 가지를 나타냅니다.

     • 4바이트 또는 6바이트 값의 두 번째 바이트는 DISCONNECT 또는 RELEASE_COMP를 받은 종단간 통화 경로의 지점을 나타냅니다.이를 통해 문제를 현지화할 수 있습니다.

     • 세 번째 및 네 번째 바이트는 실패의 실제 원인을 나타냅니다.다른 값의 의미는 표 9를 참조하십시오.

   • 가능성 2:원격 모뎀이 응답하지 않습니다.일반 전화로 원격 모뎀에 전화를 걸어 테스트합니다.다음과 같이 하십시오.

     1. 전화 번호가 올바른지 확인합니다.핸드셋을 사용하여 수신 번호를 호출합니다.

     2. 수동 통화가 응답 비동기 모뎀에 연결할 수 있는지 확인합니다.수동 통화가 응답 비동기 모뎀에 연결할 수 있는 경우 아웃바운드 음성 통화를 허용하도록 BRI 회선이 프로비저닝되지 않을 수 있습니다.

     3. 수동 통화가 응답 비동기 모뎀에 연결할 수 없는 경우 수신 모뎀의 전화 케이블을 변경하고 수신 모뎀 회선에서 일반 전화기를 사용해 보십시오.일반 전화기로 전화를 받을 수 있는 경우 수신 모뎀에 문제가 있을 수 있습니다.

     4. 수동 통화가 여전히 해당 회선의 일반 전화기에 연결할 수 없는 경우 수신 시설에서 다른(정상) 회선을 시도합니다.연결이 되면, 수신 모뎀으로 가는 전화선을 전화기에서 확인하도록 합니다.

     5. 장거리 통화인 경우 원래 측에서 다른(정상) 장거리 번호를 시도하도록 합니다.이 경우 수신 시설 또는 회선이 장거리 통화를 수신하도록 프로비저닝되지 않을 수 있습니다.원래(BRI) 회선이 다른 장거리 번호에 연결할 수 없는 경우 장거리 연결이 활성화되지 않았을 수 있습니다.다양한 장거리 회사에 1010 코드를 사용해 보십시오.

     6. 마지막으로 원래 BRI 회선에서 다른(정상 작동이 확인된) 현지 번호를 사용해 봅니다.연결이 계속 실패하면 텔코가 BRI를 확인하도록 합니다.

   • 가능성 3:전화 건 번호가 잘못되었습니다.수동으로 다이얼하여 번호를 확인합니다.필요한 경우 컨피그레이션을 수정합니다.

   • 가능성 4:모뎀 교육에 시간이 너무 오래 걸리거나 TIMEOUT 값이 너무 낮습니다.chat-script 명령에서 TIMEOUT 값을 늘려 보십시오.TIMEOUT이 이미 60초 이상인 경우 모뎀과 연결된 DTE 사이에 케이블 문제가 있을 수 있습니다.교육 실패가 회선 문제 또는 모뎀 비호환성을 나타낼 수도 있습니다.

     개별 모뎀 문제의 맨 아래로 이동하려면 리버스 텔넷으로 원래 모뎀의 AT 프롬프트로 이동합니다.가능하면 역방향 텔넷을 사용하여 수신 모뎀의 AT 프롬프트에도 연결합니다.ATM1을 사용하여 모뎀이 스피커로 소리를 보내 각 끝에 있는 사람들이 회선 상태를 들을 수 있도록 합니다.

     음악 소리가 나나요?만약 그렇다면, 회로를 청소하세요.비동기 모뎀이 작동하지 않을 경우 번호를 호출하고 정적인 소리를 듣습니다.기차 속도를 방해하는 다른 요인들이 있을 수 있다.텔넷을 비동기 모뎀으로 역수행하고 디버깅합니다.

5. 모든 것이 정상적으로 작동하지만 BRI 비동기 모뎀 DDR에 연결할 수 없는 경우 PPP 디버깅을 시도하십시오.채팅 스크립트가 성공적으로 완료되고 PPP 디버그에 오류가 있는 경우 Internetwork Troubleshooting Guide의 17장에서 "Troubleshooting PPP" 섹션을 참조하십시오.

BRI 비동기 모뎀 DDR

이 기능은 Cisco IOS Software 릴리스 12.0(3)T 이상을 사용하는 Cisco 3640 플랫폼에서만 작동합니다.BRI 네트워크 모듈의 최신 하드웨어 버전이 필요합니다.WIC(WAN Interface Card)에서는 작동하지 않습니다.

1. show modem 명령을 사용하여 국가 코드가 올바른지 확인합니다.다음 명령을 사용한 다음 전화를 시도합니다.

   경고:  사용 중인 시스템에서 디버그를 실행하면 CPU를 오버로드하거나 콘솔 버퍼를 오버런하여 라우터가 충돌할 수 있습니다.

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug bri
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. 모뎀 통화의 경우 통화를 계속하려면 채팅 스크립트를 실행해야 합니다.다이얼러 맵 기반 DDR의 경우 다이얼러 맵 명령의 modem-script 매개 변수에 의해 채팅 스크립트가 호출됩니다.DDR이 다이얼러 프로파일 기반인 경우 TTY 라인에 구성된 명령 스크립트 다이얼러가 이를 수행합니다.두 용도 모두 라우터의 전역 컨피그레이션에 존재하는 채팅 스크립트(예:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   어느 경우든 채팅 스크립트 활동을 보는 명령은 디버그 채팅입니다.다이얼러 맵 또는 다이얼러 문자열 명령에 사용된 다이얼 문자열(전화 번호)이 5551212이면 디버그 출력은 다음과 같습니다.

   CHAT1: Attempting async line dialer script
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 채팅 스크립트에서 "Sending string(전송 문자열)"을 기준으로 예상 통화(올바른 번호)를 시도하는지 확인합니다. 채팅 스크립트가 예상 통화를 시도하지 않는 경우 채팅 스크립트의 구성을 확인합니다.채팅 스크립트를 수동으로 시작하려면 exec 프롬프트에서 start-chat 명령을 사용합니다.

4. "시간 초과 예상:CONNECT"는 다음과 같은 여러 가지 가능성을 설명할 수 있습니다.

   • 가능성 1:로컬 모뎀이 실제로 전화를 걸고 있지 않습니다.모뎀에 대한 역방향 텔넷을 수행하고 수동으로 다이얼을 시작하여 모뎀을 호출할 수 있는지 확인합니다.원격 끝이 응답하지 않는 것처럼 보일 경우 ATDT<number> 명령을 사용하여 수동으로 로컬 번호를 호출하고 벨소리를 수신하여 모뎀에서 전화를 걸고 있는지 확인합니다.통화가 나오지 않으면 ISDN 디버그를 켜십시오.BRI에서 ISDN 오류가 처음 의심되는 경우 항상 show isdn 상태의 출력을 확인합니다.주목해야 할 핵심 사항은 레이어 1은 활성 상태여야 하고 레이어 2는 MULTIPLE_FRAME_ESTABLISHED 상태여야 한다는 것입니다.이 출력을 읽고 수정 조치를 읽는 방법은 네트워크 간 문제 해결 가이드 16장, "ISDN 상태 표시 해석"을 참조하십시오.

     아웃바운드 ISDN 통화의 경우 디버그 isdn q931 및 디버그 isdn 이벤트가 가장 사용하기 좋은 툴입니다.다행히 아웃바운드 통화 디버깅은 수신 통화 디버깅과 매우 유사합니다.정상적인 통화는 다음과 같습니다.

     *Mar 20 21:07:45.025: ISDN BR0: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
     

     CONNECT 메시지는 성공의 핵심 지표입니다.CONNECT가 수신되지 않은 경우 DISCONNECT 또는 RELEASE_COMP(릴리스 완료) 메시지 뒤에 원인 코드가 나타날 수 있습니다.

     *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
     callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     원인 값은 두 가지를 나타냅니다.

     • 4바이트 또는 6바이트 값의 두 번째 바이트는 DISCONNECT 또는 RELEASE_COMP를 받은 종단간 통화 경로의 지점을 나타냅니다.이를 통해 문제를 현지화할 수 있습니다.

     • 세 번째 및 네 번째 바이트는 실패의 실제 원인을 나타냅니다.다른 값의 의미는 표 9를 참조하십시오.

   • 가능성 2:원격 모뎀이 응답하지 않습니다.일반 전화로 원격 모뎀에 전화를 걸어 테스트합니다.다음과 같이 하십시오.

     1. 전화 번호가 올바른지 확인합니다.핸드셋을 사용하여 수신 번호를 호출합니다.

     2. 수동 통화가 응답 비동기 모뎀에 연결할 수 있는지 확인합니다.수동 통화가 응답 비동기 모뎀에 연결할 수 있는 경우 아웃바운드 음성 통화를 허용하도록 BRI 회선이 프로비저닝되지 않을 수 있습니다.

     3. 수동 통화가 응답 비동기 모뎀에 연결할 수 없는 경우 수신 모뎀의 전화 케이블을 변경하고 수신 모뎀 회선에서 일반 전화기를 사용해 보십시오.일반 전화기로 전화를 받을 수 있는 경우 수신 모뎀에 문제가 있을 수 있습니다.

     4. 수동 통화가 여전히 해당 회선의 일반 전화기에 연결할 수 없는 경우 수신 시설에서 다른(정상) 회선을 시도합니다.연결이 되면, 수신 모뎀으로 가는 전화선을 전화기에서 확인하도록 합니다.

     5. 장거리 통화인 경우 원래 측에서 다른(정상) 장거리 번호를 시도하도록 합니다.이 경우 수신 시설 또는 회선이 장거리 통화를 수신하도록 프로비저닝되지 않을 수 있습니다.원래(BRI) 회선이 다른 장거리 번호에 연결할 수 없는 경우 장거리 연결이 활성화되지 않았을 수 있습니다.다양한 장거리 회사에 10-10 코드를 사용해 보십시오.

     6. 마지막으로 원래 BRI 회선에서 다른(정상 작동이 확인된) 현지 번호를 사용해 봅니다.연결이 계속 실패하면 텔코가 BRI를 확인하도록 합니다.

   • 가능성 3:전화 건 번호가 잘못되었습니다.수동으로 다이얼하여 번호를 확인합니다.필요한 경우 컨피그레이션을 수정합니다.

   • 가능성 4:모뎀 교육에 시간이 너무 오래 걸리거나 TIMEOUT 값이 너무 낮습니다.chat-script 명령에서 TIMEOUT 값을 늘려 보십시오.TIMEOUT이 이미 60초 이상인 경우 모뎀과 연결된 DTE 사이에 케이블 문제가 있을 수 있습니다.교육 실패가 회선 문제 또는 모뎀 비호환성을 나타낼 수도 있습니다.

     개별 모뎀 문제의 맨 아래로 이동하려면 리버스 텔넷으로 원래 모뎀의 AT 프롬프트로 이동합니다.가능하면 역방향 텔넷을 사용하여 수신 모뎀의 AT 프롬프트에도 연결합니다.ATM1을 사용하여 모뎀이 스피커로 소리를 보내 각 끝에 있는 사람들이 회선 상태를 들을 수 있도록 합니다.

     음악 소리가 나나요?만약 그렇다면, 회로를 청소하세요.비동기 모뎀이 작동하지 않을 경우 번호를 호출하고 정적인 소리를 듣습니다.기차 속도를 방해하는 다른 요인들이 있을 수 있다.텔넷을 비동기 모뎀으로 역수행하고 디버깅합니다.

5. 모든 것이 정상적으로 작동하지만 BRI 비동기 모뎀 DDR에 연결할 수 없는 경우 PPP 디버깅을 시도하십시오.채팅 스크립트가 성공적으로 완료되고 PPP 디버그에 오류가 있는 경우 Internetwork Troubleshooting Guide의 17장에서 "Troubleshooting PPP" 섹션을 참조하십시오.

PRI ISDN DDR

1. PRI에서 ISDN 오류가 처음 발생한 경우 항상 show isdn 상태의 출력을 확인합니다.주목해야 할 핵심 사항은 레이어 1은 활성 상태이고 레이어 2는 MULTIPLE_FRAME_ESTABLISHED 상태여야 한다는 것입니다.이 출력을 읽고 수정 조치를 읽는 방법은 네트워크 간 문제 해결 가이드 16장, "ISDN 상태 표시 해석"을 참조하십시오.

   아웃바운드 ISDN 통화의 경우 디버그 isdn q931 및 디버그 isdn 이벤트가 가장 사용하기 좋은 툴입니다.다행히 아웃바운드 통화 디버깅은 수신 통화 디버깅과 매우 유사합니다.정상적인 통화는 다음과 같습니다.

   *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
   Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
   callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
   

   CONNECT 메시지는 성공의 핵심 지표입니다.CONNECT가 수신되지 않은 경우 DISCONNECT 또는 RELEASE_COMP(릴리스 완료) 메시지 뒤에 원인 코드가 나타날 수 있습니다.

   *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   원인 값은 두 가지를 나타냅니다.

   • 4바이트 또는 6바이트 값의 두 번째 바이트는 DISCONNECT 또는 RELEASE_COMP를 받은 종단간 통화 경로의 지점을 나타냅니다.이를 통해 문제를 현지화할 수 있습니다.

   • 세 번째 및 네 번째 바이트는 실패의 실제 원인을 나타냅니다.다른 값의 의미는 표 9를 참조하십시오.

   참고: 다음 인쇄물은 더 높은 프로토콜 오류를 나타냅니다.

   Cause i = 0x8090 - Normal call clearing

   PPP 인증 실패가 일반적인 이유입니다.연결 실패가 반드시 ISDN 문제임을 가정하기 전에 디버그 ppp 협상 및 debug ppp 인증을 설정합니다.

2. ISDN CONNECT 메시지가 표시되고 PPP 디버그가 장애를 나타내는 경우 Internetwork Troubleshooting Guide 17장의 "Troubleshooting PPP" 섹션을 참조하십시오.

BRI ISDN DDR

1. BRI에서 ISDN 오류가 처음 의심되는 경우 항상 show isdn status의 출력을 확인합니다.주목해야 할 핵심 사항은 레이어 1은 활성 상태이고 레이어 2는 MULTIPLE_FRAME_ESTABLISHED 상태여야 한다는 것입니다.이 출력 읽기 및 수정 조치에 대한 자세한 내용은 Internetwork Troubleshooting Guide Chapter 16, "Ingoating ISDN Status" 를 참조하십시오.

   아웃바운드 ISDN 통화의 경우 디버그 isdn q931 및 디버그 isdn 이벤트가 가장 사용하기 좋은 툴입니다.다행히 아웃바운드 통화 디버깅은 수신 통화 디버깅과 매우 유사합니다.정상적인 통화는 다음과 같습니다.

   *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
   *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
   

   CONNECT 메시지는 성공의 핵심 지표입니다.CONNECT가 수신되지 않은 경우 DISCONNECT 또는 RELEASE_COMP(릴리스 완료) 메시지 뒤에 원인 코드가 나타날 수 있습니다.

   *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   원인 값은 두 가지를 나타냅니다.

   • 4바이트 또는 6바이트 값의 두 번째 바이트는 DISCONNECT 또는 RELEASE_COMP를 받은 종단간 통화 경로의 지점을 나타냅니다.이를 통해 문제를 현지화할 수 있습니다.

   • 세 번째 및 네 번째 바이트는 실패의 실제 원인을 나타냅니다.다른 값의 의미는 표 9를 참조하십시오.

     참고: 다음 인쇄물은 더 높은 프로토콜 오류를 나타냅니다.

     Cause i = 0x8090 - Normal call clearing

     PPP 인증 실패가 일반적인 이유입니다.연결 실패가 반드시 ISDN 문제임을 가정하기 전에 디버그 ppp 협상 및 debug ppp 인증을 설정합니다.

2. ISDN CONNECT 메시지가 표시되고 PPP 디버그가 장애를 나타내는 경우 Internetwork Troubleshooting Guide 17장의 "Troubleshooting PPP" 섹션을 참조하십시오.

관련 정보

• Cisco IOS Dial Services 빠른 구성 설명서
• Cisco IOS Dial Services 컨피그레이션 가이드:네트워크 서비스
• Cisco IOS Dial Services 컨피그레이션 가이드:터미널 서비스
• Cisco IOS Dial Services 명령 참조
• 다이얼 사례 연구 개요
• 액세스 기술 페이지
• 기술 지원 및 문서 − Cisco Systems