전화 접속 기술:문제 해결 기법

다운로드 옵션

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

편견 없는 언어

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

이 번역에 관하여

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

소개

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

사전 요구 사항

요구 사항

이 문서의 독자는 다음 내용을 숙지해야 합니다.

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

첫 번째 액세스 서버는 Cisco2509와 Cisco2511입니다. 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 기술 팁 표기 규칙을 참조하십시오.

수신 통화 문제 해결

수신 통화의 문제 해결은 하단에서 시작되어 진행 중입니다.추론의 일반적인 흐름은 다음과 같습니다.

  1. 통화가 도착하는 것 같습니까?(예를 선택하면 다음 질문으로 넘어갑니다.)

  2. 수신 끝부분이 통화에 응답합니까?

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

  4. 데이터가 링크를 통과합니까?

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

모뎀 연결의 경우 데이터 통화는 데이터 통화가 PPP를 협상하기 위해 오는 종료 시점까지 들어오는 터미널 세션과 같습니다.

디지털 모뎀과 관련된 수신 통화의 경우 먼저 기본 ISDN 또는 CAS가 통화를 수신하는지 확인합니다.외부 모뎀을 사용하는 경우 ISDN 및 CAS 그룹 섹션을 건너뛸 수 있습니다.

수신 ISDN 통화 문제 해결

debug isdn q931 명령을 사용합니다. 성공적인 연결의 출력 예는 다음과 같습니다. 

Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

설정 메시지는 원격 종단에서 연결을 시작하고 있음을 나타냅니다.통화 참조 번호는 쌍으로 유지됩니다.이 경우 연결의 수신 쪽에 대한 통화 참조 번호는 0x06이고 연결의 아웃바운드 측면의 통화 참조 번호는 0x86입니다. 베어러 기능(bearrcap이라고도 함)은 라우터에 어떤 종류의 통화가 수신되는지 알려줍니다.이 경우 연결은 0x8890 유형입니다. 이 값은 "ISDN Speed 64Kb/s"를 나타냅니다. 비어캡이 0x8090A2였다면 "음성/음성 통화 u-law"로 표시했을 것입니다.

설정 메시지가 수신되지 않은 경우 음성 프로비저닝인 경우 수동으로 전화를 걸어 정확한 번호를 확인해야 합니다.ISDN 인터페이스의 상태도 확인해야 합니다(BRI 문제 해결을 위해 show isdn status 명령 사용 참조). 모두 체크 아웃된 경우 통화 발신자가 올바른 통화를 수행하고 있는지 확인합니다.이 작업은 전화 회사에 연락하여 수행할 수 있습니다.통화 발신자는 통화가 전송되는 위치를 확인하기 위해 통화를 추적할 수 있습니다.연결이 장거리 연결인 경우 1010 장거리 코드를 사용하여 다른 장거리 통신업체를 사용해 보십시오.

수신 통화가 비동기 모뎀 통화인 경우 음성 통화를 허용하도록 회선이 프로비저닝되었는지 확인합니다.

참고: BRI 비동기 모뎀 호출은 12.0(3)T 이상을 실행하는 3600 라우터의 기능입니다.BRI 인터페이스 네트워크 모듈의 최신 하드웨어 버전이 필요합니다.WIC 모듈은 비동기 모뎀 호출을 지원하지 않습니다.

통화가 도착했지만 완료되지 않은 경우 원인 코드를 찾습니다(표 17-10 참조).성공적으로 완료되면 connect-ack이 표시됩니다.

비동기 모뎀 호출인 경우 "수신 모뎀 통화 문제 해결" 섹션으로 이동합니다.

이 시점에서 ISDN 통화가 연결되었지만 링크를 통해 전달되는 데이터가 보이지 않습니다.디버그 ppp 협상 명령을 사용하여 PPP 트래픽이 회선을 통과하는지 확인합니다.트래픽이 표시되지 않으면 속도가 일치하지 않을 수 있습니다.이 경우 show running-config privileged exec 명령을 사용하여 라우터 컨피그레이션을 확인합니다.로컬 및 원격 라우터에서 다이얼러 맵 인터페이스 컨피그레이션 명령 항목을 확인합니다.이러한 항목은 다음과 비슷해야 합니다. 

dialer map ip 131.108.2.5 speed 56 name C4000

다이얼러 프로파일의 경우 속도를 설정하려면 맵 클래스를 정의해야 합니다.기본적으로 ISDN 인터페이스는 각 채널에서 64K 통신 속도를 사용합니다.

다이얼러 맵 및 프로필 구성에 대한 자세한 내용은 Cisco IOS Dial Solutions Configuration Guide, Dial Solutions Command Reference 및 Dial Solutions Quick Configuration Guide를 참조하십시오.

유효한 PPP 패킷을 수신하면 링크가 작동 중입니다.지금 "Troubleshooting PPP(PPP 문제 해결)" 섹션을 진행해야 합니다.

수신 CAS 통화 문제 해결

모뎀에 대한 연결을 제공하는 CAS 그룹의 문제를 해결하려면 디버그 모뎀, 디버그 모뎀 csm 및 디버그 cas 명령을 사용합니다.

참고: debug cas 명령은 AS5200 및 AS5300의 경우 12.0(7)T에 처음 나타납니다. 이전 버전의 IOS에서는 exec 명령 modem-mgmt rbs와 함께 시스템 수준 구성 명령 서비스 내부를 사용합니다.AS5800에서 이 정보를 디버깅하려면 트렁크 카드 자체에 연결해야 합니다.

먼저, 전화 회사 스위치가 수신 전화에 신호를 보내기 위해 "오프로후크"되었는지 확인합니다.그렇지 않은 경우 호출할 번호를 확인합니다.이 작업을 수행하려면 전화기를 원래 쪽 전화선에 연결하고 번호로 전화를 겁니다.통화가 제대로 수신되면 문제가 원래 CPE에 있습니다.CAS에 여전히 통화가 표시되지 않으면 T1(15장)을 확인합니다.이 인스턴스에서 debug serial interfaces 명령을 사용합니다.

다음은 디버그 모뎀 CSM을 사용하는 올바른 연결입니다. 

Router# debug modem csm
CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.
MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0
CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
CSM_RING_INDICATION_PROC: RI is on
CSM_RING_INDICATION_PROC: RI is off
CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0
CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0

이 예에서는 통화가 모뎀으로 전송되었습니다.통화가 모뎀으로 전달된 경우 아래의 "수신 모뎀 통화 문제 해결" 섹션으로 진행합니다.

수신 모뎀 통화 문제 해결

수신 모뎀 통화 문제 해결 시 다음 디버그 명령을 사용합니다.

  • 디버그 모뎀

  • 디버그 모뎀 csm(통합 디지털 모뎀용)

다음 디버그 명령을 함께 사용하여 새 통화가 수신됨을 나타냅니다.

  • 디버그 isdn q931

  • 디버그 cas

통화가 모뎀에 도달하면 모뎀에서 전화를 받아야 합니다.

외부 모뎀 디버깅 팁

TTY 회선에 연결된 외부 모뎀에서 디버깅을 용이하게 하려면 스피커 볼륨을 높입니다.이는 몇 가지 문제를 더 명확하게 하는 데 도움이 됩니다.

원래 모뎀이 전화를 걸면 수신 모뎀이 울립니까?그렇지 않은 경우 번호를 확인하고 원격 사이트에서 수동으로 전화를 걸어 보십시오.수신 끝에서도 일반 전화기를 사용해 보십시오.필요한 경우 케이블과 하드웨어를 교체합니다.

비동기 모뎀 통화 당겨받기

외부 모뎀이 응답하지 않는 경우 모뎀과 액세스 서버 또는 라우터 사이의 케이블을 확인합니다.롤드 RJ-45 케이블 및 MMOD DB-25 어댑터를 사용하여 모뎀이 라우터의 TTY 또는 보조 포트에 연결되었는지 확인합니다.Cisco는 RJ-45 포트에 대해 이 케이블 컨피그레이션을 권장 및 지원합니다.이러한 커넥터는 일반적으로 다음과 같은 레이블이 지정됩니다.모뎀.

RJ-45 케이블은 다음과 같은 몇 가지 유형으로 제공됩니다.직선, 롤링 및 크로스오버RJ-45 케이블의 양쪽 끝을 나란히 놓아 케이블 유형을 결정할 수 있습니다.각 끝에 8개의 색상 스트립 또는 핀이 있습니다.

  • 색상 핀의 순서가 각 끝에서 동일하면 케이블이 직선으로 표시됩니다.

  • 색상 순서가 각 끝에서 반전되면 케이블이 롤오버됩니다.

  • 색상이 다음과 같은 경우 케이블은 크로스오버 케이블입니다.

RJ45-RJ45 크로스오버 케이블: 

RJ45                  RJ45 
         5 ------------------ 2
         2 ------------------ 5
         4 ------------------ 1 
         1 ------------------ 4

신호 처리가 정상인지 확인하려면 16장에 설명된 show line 명령을 사용합니다.

케이블 연결 문제는 제외하고 자동으로 응답하려면 외부 모뎀을 초기화해야 합니다.원격 모뎀이 자동 응답으로 설정되어 있는지 확인합니다.일반적으로 자동 응답이 설정되면 AA 표시등 표시등이 켜집니다.원격 모뎀이 아직 설정되지 않은 경우 자동 응답으로 설정합니다.모뎀 설정 확인 및 변경에 대한 자세한 내용은 모뎀 설명서를 참조하십시오.역방향 텔넷을 사용하여 모뎀을 초기화합니다(16장 참조).

디지털(통합) 모뎀 통화 당겨받기

외부 모뎀에서 통화에 응답하는지 여부는 분명하지만 내부 모뎀에서는 수신 번호로 수동 전화를 걸어야 합니다.응답 신호음(ABT)을 듣습니다. ABT가 들리지 않으면 다음 두 가지 구성 사항을 확인하십시오.

  1. 수신 모뎀 연결을 처리하는 ISDN 인터페이스 아래에 isdn incoming-voice modem 명령이 있는지 확인합니다.

  2. 모뎀의 TTY에 대한 회선 구성 아래에서 명령 모뎀이 있는지 확인합니다.

CSM(Call Switching Module)에서 수신 통화를 처리하기 위해 내부 모뎀을 할당하지 않았을 수도 있습니다.이 문제는 너무 적은 수의 수신 연결에 대해 모뎀 또는 리소스 풀을 구성하는 경우 발생할 수 있습니다.또한 액세스 서버가 모뎀이 없을 수도 있습니다.모뎀의 가용성을 확인하고 모뎀 풀 또는 리소스 풀 관리자 설정을 적절하게 조정합니다.모뎀이 할당되고 구성에 모뎀이 입력되어 있으면 디버그를 수집하고 Cisco에 문의하십시오.

모뎀 교육

수신 모뎀에서 DSR을 발생시키는 경우 교육에 성공했습니다.교육 실패가 회선 문제 또는 모뎀 비호환성을 나타낼 수 있습니다.

개별 모뎀 문제의 맨 아래로 이동하려면 관심 있는 POTS 라인에 연결된 상태에서 원래 모뎀의 AT 프롬프트로 이동합니다.Cisco 액세스 서버에서 디지털 모뎀으로 전화를 걸 경우 교육 음악의 .wav 파일 또는 DIL(Digital Disactation Learning Sequence)을 기록할 준비를 해야 합니다. DIL은 원래 V.90 아날로그 모뎀이 받는 디지털 모뎀에 재생하도록 지시하는 음악 점수(PCM 시퀀스)입니다.이 순서를 통해 아날로그 모뎀은 회로의 디지털 장애를 식별할 수 있습니다.다중 D/A 변환, 법률/u-law, 도난 비트 또는 디지털 패드와 같은 작업을 수행합니다.DIL을 듣지 않으면 모뎀이 V.8/V.8bis에서 V.90을 협상하지 않았습니다(즉, 모뎀 호환성 문제). V.34에서 DIL과 리트레인 소리가 들리면 아날로그 모뎀은 V.90이 실행 불가능한 것으로 판단했습니다(DIL 재생을 기준으로).

음악 소리가 나나요?그렇다면 회로를 청소합니다.

고객은 V.34 교육을 실행하지 않고 신속하게 포기합니까?예를 들어, V.8bis를 들을 때 무엇을 해야 할지 모를 수도 있습니다.이 경우 서버에서 V.8bis(따라서 K56Flex)를 비활성화해야 합니다(허용되는 경우). 새 클라이언트 펌웨어를 가져오거나 클라이언트 모뎀을 교체해야 합니다.또는 다이얼링 끝은 다이얼 문자열의 끝에 쉼표 5개를 삽입할 수 있습니다.이렇게 하면 발신 모뎀의 수신 대기 시간이 지연되며 클라이언트 모뎀에 영향을 주지 않고 수신 서버에서 V.8bis 신호음이 시간 초과됩니다.다이얼 문자열의 쉼표는 일반적인 지침이며 로컬 조건을 허용하도록 조정해야 할 수 있습니다.

세션 설정

이 순서로 모뎀이 연결되고 교육됩니다.이제 트래픽이 제대로 전달되는지 확인할 때입니다.

통화 수신 회선이 자동 선택 ppp로 구성되고 비동기 인터페이스가 비동기 모드 인터랙티브로 구성된 경우 디버그 모뎀 명령을 사용하여 자동 선택 프로세스를 확인합니다.트래픽이 비동기 링크를 통해 들어올 때 액세스 서버는 트래픽을 검사하여 트래픽이 문자 기반인지 패킷 기반인지 확인합니다.결정에 따라 액세스 서버는 PPP 세션을 시작하거나 라인에 exec 세션을 보유하는 것보다 더 멀리 가지 않습니다.

인바운드 PPP LCP 패킷이 포함된 일반 자동 선택 시퀀스: 

*Mar  1 21:34:56.958: TTY1: DSR came up
*Mar  1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar  1 21:34:56.970: TTY1: EXEC creation
*Mar  1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar  1 21:34:59.722: TTY1: Autoselect(2) sample 7E 

!--- The inbound traffic is displayed in hexadecimal format. This is based on the !--- bits coming in over the line, regardless of whether the bits are ASCII !--- characters or elements of a packet. The bits represented in this example are !--- correct for a LCP packet. Anything different would be either a malformed packet !--- or character traffic.

*Mar  1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar  1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate 

!--- Having determined that the inbound traffic is actually an LCP packet, the access !--- server triggers the PPP negotiation process.

*Mar  1 21:34:59.746: TTY1: EXEC creation
*Mar  1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar  1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar  1 21:34:59.794: TTY1: destroy timer type 0
*Mar  1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up 

!--- The async interface changes state to up, and the PPP negotiation (not shown) !--- commences.

통화가 PPP 세션이고 비동기 모드 전용이 비동기 인터페이스에 구성된 경우 디버그 ppp 협상 명령을 사용하여 원격 엔드로부터 컨피그레이션 요청 패킷이 오는지 확인합니다.디버그에는 이러한 내용이 CONFREQ로 표시됩니다.인바운드 및 아웃바운드 PPP 패킷을 모두 관찰하는 경우 "Troubleshooting PPP(PPP 문제 해결)"로 진행합니다. 그렇지 않으면 통화 시작 끝의 문자 모드(또는 "exec") 세션(즉, 비 PPP 세션)을 사용하여 연결합니다.

참고: 수신 엔드가 비동기 인터페이스 아래 전용 비동기 모뎀을 표시하는 경우 exec dial-in은 임의의 ASCII 가비지 표시만 표시합니다.터미널 세션을 허용하고 PPP 기능을 계속 사용하려면 async interface configuration 명령 async mode interactive를 사용합니다.연결된 행의 컨피그레이션에서 autoselect ppp 명령을 사용합니다.

모뎀에서 데이터를 보내거나 받을 수 없음

모뎀이 터미널 세션과 연결되고 데이터가 전달되지 않는 경우 다음과 같은 가능한 원인과 권장 작업 과정을 확인하십시오.

  • 모뎀 속도 설정이 잠기지 않았습니다.

    1. 액세스 서버 또는 라우터에서 show line exec 명령을 사용합니다.보조 포트의 출력은 현재 구성된 Tx 및 Rx 속도를 나타내야 합니다.

      show line 명령의 출력에 대한 설명은 15장의 "Using Debug Commands" 섹션을 참조하십시오.

    2. 회선이 올바른 속도로 구성되지 않은 경우 speed line configuration 명령을 사용하여 액세스 서버 또는 라우터 회선에서 회선 속도를 설정합니다.값을 모뎀과 액세스 서버 또는 라우터 포트 간에 공통으로 가장 빠른 속도로 설정합니다.터미널 전송 속도를 설정하려면 speed line configuration 명령을 사용합니다.이 명령은 전송(터미널로) 및 수신(터미널에서) 속도를 모두 설정합니다.

      구문:

      속도 bps

      구문 설명:

      bps - 전송 속도(bps) 기본값은 9600bps입니다.

      다음 예는 Cisco 2509 액세스 서버의 라인 1과 2를 115200bps로 설정합니다.

      line 1 2
speed 115200

      참고: 어떤 이유로 흐름 제어를 사용할 수 없는 경우 라인 속도를 9600bps로 제한합니다.속도가 빨라지면 데이터가 손실될 가능성이 높습니다.

    3. show line exec 명령을 다시 사용하고 라인 속도가 원하는 값으로 설정되어 있는지 확인합니다.

    4. 액세스 서버 또는 라우터 회선이 원하는 속도로 구성되어 있으면 해당 회선을 통해 모뎀에 대한 역방향 텔넷 세션을 시작합니다.자세한 내용은 16장의 "모뎀에 대한 역방향 텔넷 세션 설정" 절을 참조하십시오.

    5. 모뎀에 "lock DTE speed" 명령을 포함하는 모뎀 명령 문자열을 사용합니다.정확한 컨피그레이션 명령 구문은 모뎀 설명서를 참조하십시오.

    참고: 포트 속도 조정 또는 버퍼링 모드라고도 하는 lock DTE speed 명령은 모뎀이 오류 수정을 처리하는 방식과 관련된 경우가 많습니다.이 명령은 모뎀마다 다릅니다.

    모뎀 속도를 잠그면 모뎀이 항상 Cisco 보조 포트에 구성된 속도로 Cisco 액세스 서버 또는 라우터와 통신합니다.이 명령을 사용하지 않으면 모뎀은 액세스 서버에 구성된 속도로 통신하는 대신 데이터 링크(전화 회선)의 속도로 되돌아갑니다.

  • 로컬 또는 원격 모뎀 또는 라우터에 하드웨어 흐름 제어가 구성되지 않음

    1. show line aux-line-number exec 명령을 사용하고 Capabilities(기능) 필드에서 다음을 확인합니다. 

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      자세한 내용은 16장의 선 출력 표시 해석을 참조하십시오.

      이 필드에 하드웨어 흐름 제어에 대한 언급이 없는 경우, 하드웨어 흐름 제어가 라인에서 활성화되지 않습니다.액세스 서버-모뎀 연결을 위한 하드웨어 흐름 제어가 권장됩니다.

      show line 명령의 출력에 대한 자세한 내용은 15장의 "Using Debug Commands" 단원을 참조하십시오.

    2. flowcontrol hardware line configuration 명령을 사용하여 행에서 하드웨어 흐름 제어를 구성합니다.

      터미널 또는 다른 직렬 장치와 라우터 간에 데이터 흐름 제어 방법을 설정하려면 flowcontrol line configuration 명령을 사용합니다.흐름 제어를 비활성화하려면 이 명령의 no 형식을 사용합니다.

      구문:

      flowcontrol {없음 | 소프트웨어 [잠금] [입력 | 출력] | 하드웨어 [in | 출력]}

      구문 설명:

      • none - 흐름 제어를 해제합니다.

      • software - 소프트웨어 흐름 제어를 설정합니다.선택 키워드는 방향을 지정합니다.에서 Cisco IOS 소프트웨어가 연결된 디바이스에서 흐름 제어를 수신하고 out을 수행하면 소프트웨어가 연결된 디바이스에 흐름 제어 정보를 전송합니다.방향을 지정하지 않으면 둘 다 가정됩니다.

      • lock - 연결된 디바이스에 소프트웨어 흐름 제어가 필요한 경우 원격 호스트에서 흐름 제어를 해제할 수 없게 합니다.이 옵션은 텔넷 또는 로그인 프로토콜을 사용하는 연결에 적용됩니다.

      • hardware - 하드웨어 흐름 제어를 설정합니다.선택 키워드는 방향을 지정합니다.에서 소프트웨어가 연결된 디바이스에서 흐름 제어를 수신하고 out을 수행하면 소프트웨어가 연결된 디바이스에 흐름 제어 정보를 전송합니다.방향을 지정하지 않으면 둘 다 가정됩니다.하드웨어 흐름 제어에 대한 자세한 내용은 라우터와 함께 제공된 하드웨어 설명서를 참조하십시오.

      예:

      다음 예는 행 7에서 하드웨어 흐름 제어를 설정합니다. 

      line 7
flowcontrol hardware

      참고: 어떤 이유로 흐름 제어를 사용할 수 없는 경우 라인 속도를 9600bps로 제한합니다.속도가 빨라지면 데이터가 손실될 가능성이 높습니다.

    3. 액세스 서버 또는 라우터 회선에서 하드웨어 흐름 제어를 활성화한 후 해당 회선을 통해 모뎀에 대한 역방향 텔넷 세션을 시작합니다.자세한 내용은 16장의 "모뎀에 대한 역방향 텔넷 세션 설정" 절을 참조하십시오.

    4. 모뎀에 대해 RTS/CTS Flow 명령을 포함하는 모뎀 명령 문자열을 사용합니다.이 명령은 모뎀이 Cisco 액세스 서버 또는 라우터와 동일한 흐름 제어 방법(즉, 하드웨어 흐름 제어)을 사용하고 있는지 확인합니다.정확한 컨피그레이션 명령 구문은 모뎀 설명서를 참조하십시오.

  • 잘못 구성된 다이얼러 맵 명령

    1. show running-config privileged exec 명령을 사용하여 라우터 컨피그레이션을 확인합니다.dialer map 명령 항목을 확인하여 broadcast 키워드가 지정되었는지 확인합니다.

    2. 키워드가 없으면 컨피그레이션에 추가합니다.

      구문:

      다이얼러 맵 프로토콜 next-hop-address [name hostname] [broadcast] [dial-string]

      구문 설명:

      • protocol - 매핑이 적용되는 프로토콜입니다.옵션에는 IP, IPX, 브리지 및 스냅샷이 포함됩니다.

      • next-hop-address - 반대 사이트의 비동기 인터페이스의 프로토콜 주소입니다.

      • name hostname - PPP 인증에 사용되는 필수 매개 변수입니다.다이얼러 맵이 생성된 원격 사이트의 이름입니다.이름은 대/소문자를 구분하며 원격 라우터의 호스트 이름과 일치해야 합니다.

      • broadcast - 원격 대상으로 전달되는 패킷(예: IP RIP 또는 IPX RIP/SAP 업데이트)을 브로드캐스트하는 선택적 키워드입니다.정적 라우팅 샘플 컨피그레이션에서는 라우팅 업데이트가 필요하지 않으며 broadcast 키워드가 생략됩니다.

      • dial-string - 원격 사이트의 전화 번호입니다.모든 액세스 코드(예: 사무실에서 나가기 위해 9개, 국제 전화 코드, 지역 코드)가 포함되어야 합니다.

    3. 다이얼러 맵 명령이 올바른 다음 hop 주소를 지정하는지 확인합니다.

    4. 다음 hop 주소가 올바르지 않으면 dialer map 명령을 사용하여 변경합니다.

    5. 다이얼러 맵 명령의 다른 모든 옵션이 사용 중인 프로토콜에 대해 올바르게 지정되었는지 확인합니다.

    다이얼러 맵 구성에 대한 자세한 내용은 Cisco IOS Wide-Area Networking 컨피그레이션 가이드 및 WAN 명령 참조를 참조하십시오.

  • 모뎀 전화 걸기 문제

    • 다이얼링 모뎀이 작동 중이고 올바른 포트에 안전하게 연결되어 있는지 확인합니다.다른 모뎀이 동일한 포트에 연결되었을 때 작동하는지 확인합니다.

수신 EXEC 세션 디버깅은 일반적으로 몇 가지 주요 범주로 분류됩니다.

전화 접속 클라이언트가 실행 프롬프트 없음

  • 라인에서 자동 선택을 사용할 수 있습니다.

    Enter 키를 눌러 exec 모드에 액세스하려고 합니다.

  • no exec 명령으로 회선 구성

    1. show line exec 명령을 사용하여 해당 행의 상태를 볼 수 있습니다.

      Capabilities(기능) 필드를 확인하여 "exec suppressed(exec 숨김)"라고 표시되는지 확인합니다. 이 경우 no exec line configuration 명령이 활성화됩니다.

    2. exec 세션을 시작할 수 있도록 행에서 exec line configuration 명령을 구성합니다.이 명령에는 인수 또는 키워드가 없습니다.

    다음 예는 행 7에서 exec을 설정합니다. 

    line 7 
exec

  • 흐름 제어를 사용할 수 없습니다.

    또는

    플로우 제어는 하나의 디바이스(DTE 또는 DCE)에서만 활성화됩니다.

    또는

    흐름 제어가 잘못 구성되었습니다.

    1. show line aux-line-number exec 명령을 사용하고 Capabilities(기능) 필드에서 다음을 확인합니다. 

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      자세한 내용은 16장의 선 출력 표시 해석을 참조하십시오.

      이 필드에 하드웨어 흐름 제어에 대한 언급이 없는 경우, 하드웨어 흐름 제어가 라인에서 활성화되지 않습니다.액세스 서버-모뎀 연결을 위한 하드웨어 흐름 제어가 권장됩니다.

      show line 명령의 출력에 대한 자세한 내용은 15장의 "디버그 명령 사용" 섹션을 참조하십시오.

    2. flowcontrol 하드웨어 라인 컨피그레이션 명령을 사용하여 행에서 하드웨어 흐름 제어를 구성합니다.다음 예는 행 7에서 하드웨어 흐름 제어를 설정합니다. 

      line 7
flowcontrol hardware

      참고: 어떤 이유로 흐름 제어를 사용할 수 없는 경우 라인 속도를 9600bps로 제한합니다.속도가 빨라지면 데이터가 손실될 가능성이 높습니다.

    3. 액세스 서버 또는 라우터 회선에서 하드웨어 흐름 제어를 활성화한 후 해당 회선을 통해 모뎀에 대한 역방향 텔넷 세션을 시작합니다.자세한 내용은 16장의 "모뎀에 대한 역방향 텔넷 세션 설정" 절을 참조하십시오.

    4. 모뎀에 RTS/CTS Flow 명령을 포함하는 모뎀 명령 문자열을 사용합니다.이 명령은 모뎀이 Cisco 액세스 서버 또는 라우터와 동일한 흐름 제어 방법(즉, 하드웨어 흐름 제어)을 사용하고 있는지 확인합니다.정확한 컨피그레이션 명령 구문은 모뎀 설명서를 참조하십시오.

  • 모뎀 속도 설정이 잠기지 않았습니다.

    1. 액세스 서버 또는 라우터에서 show line exec 명령을 사용합니다.보조 포트의 출력은 현재 구성된 Tx 및 Rx 속도를 나타내야 합니다.

      show line 명령의 출력에 대한 자세한 내용은 15장의 "디버그 명령 사용" 섹션을 참조하십시오.

    2. 회선이 올바른 속도로 구성되지 않은 경우 speed line configuration 명령을 사용하여 액세스 서버 또는 라우터 회선에서 회선 속도를 설정합니다.값을 모뎀과 액세스 서버 또는 라우터 포트 간에 공통으로 가장 빠른 속도로 설정합니다.터미널 전송 속도를 설정하려면 speed line configuration 명령을 사용합니다.이 명령은 전송(터미널로) 및 수신(터미널에서) 속도를 모두 설정합니다.

      구문:

      속도 bps

      구문 설명:

      bps - 전송 속도(bps) 기본값은 9600bps입니다.

      예:

      다음 예는 Cisco 2509 액세스 서버의 라인 1과 2를 115200bps로 설정합니다. 

      line 1 2
speed 115200

      참고: 어떤 이유로 흐름 제어를 사용할 수 없는 경우 라인 속도를 9600bps로 제한합니다.속도가 빨라지면 데이터가 손실될 가능성이 높습니다.

    3. show line exec 명령을 다시 사용하고 라인 속도가 원하는 값으로 설정되어 있는지 확인합니다.

    4. 액세스 서버 또는 라우터 회선이 원하는 속도로 구성되어 있으면 해당 회선을 통해 모뎀에 대한 역방향 텔넷 세션을 시작합니다.자세한 내용은 16장의 "모뎀에 대한 역방향 텔넷 세션 설정" 절을 참조하십시오.

    5. 모뎀에 대해 lock DTE speed 명령을 포함하는 모뎀 명령 문자열을 사용합니다.정확한 컨피그레이션 명령 구문은 모뎀 설명서를 참조하십시오.

    참고: 포트 속도 조정 또는 버퍼링 모드라고도 하는 lock DTE speed 명령은 모뎀에서 오류 수정을 처리하는 방법과 관련이 있습니다.이 명령은 모뎀마다 다릅니다.

    모뎀 속도를 잠그면 모뎀이 항상 Cisco 보조 포트에 구성된 속도로 Cisco 액세스 서버 또는 라우터와 통신합니다.이 명령을 사용하지 않으면 모뎀은 액세스 서버에 구성된 속도로 통신하는 대신 데이터 링크(전화 회선)의 속도로 돌아갑니다.

전화 접속 세션에 "불필요한 정보"가 표시됨

  • 모뎀 속도 설정이 잠기지 않았습니다.

    1. 액세스 서버 또는 라우터에서 show line exec 명령을 사용합니다.보조 포트의 출력은 현재 구성된 Tx 및 Rx 속도를 나타내야 합니다.

      show line 명령의 출력에 대한 설명은 15장의 "Using Debug Commands" 섹션을 참조하십시오.

    2. 회선이 올바른 속도로 구성되지 않은 경우 speed line configuration 명령을 사용하여 액세스 서버 또는 라우터 회선에서 회선 속도를 설정합니다.값을 모뎀과 액세스 서버 또는 라우터 포트 간에 공통으로 가장 빠른 속도로 설정합니다.

      터미널 전송 속도를 설정하려면 speed line configuration 명령을 사용합니다.이 명령은 전송(터미널로) 및 수신(터미널에서) 속도를 모두 설정합니다.

      구문:

      속도 bps

      구문 설명:

      bps 전송 속도(bps) 기본값은 9600bps입니다.

      예:

      다음 예는 Cisco 2509 액세스 서버의 라인 1과 2를 115200bps로 설정합니다.

      라인 1 2

      속도 115200

      참고: 어떤 이유로 흐름 제어를 사용할 수 없는 경우 라인 속도를 9600bps로 제한합니다.속도가 빨라지면 데이터가 손실될 가능성이 높습니다.

    3. show line exec 명령을 다시 사용하고 라인 속도가 원하는 값으로 설정되어 있는지 확인합니다.

    4. 액세스 서버 또는 라우터 회선이 원하는 속도로 구성되어 있으면 해당 회선을 통해 모뎀에 대한 역방향 텔넷 세션을 시작합니다.자세한 내용은 16장의 "모뎀에 대한 역방향 텔넷 세션 설정" 절을 참조하십시오.

    5. 모뎀에 대해 lock DTE speed 명령을 포함하는 모뎀 명령 문자열을 사용합니다.정확한 컨피그레이션 명령 구문은 모뎀 설명서를 참조하십시오.

    참고: lock DTE speed 명령(포트 속도 조정 또는 버퍼링 모드)은 모뎀에서 오류 수정을 처리하는 방법과 관련이 있습니다.이 명령은 모뎀마다 다릅니다.

    모뎀 속도를 잠그면 모뎀이 항상 Cisco 보조 포트에 구성된 속도로 Cisco 액세스 서버 또는 라우터와 통신합니다.이 명령을 사용하지 않으면 모뎀은 액세스 서버에 구성된 속도로 통신하는 대신 데이터 링크(전화 회선)의 속도로 돌아갑니다.

증상:다른 사용자가 시작한 기존 세션에서 원격 전화 접속 세션이 열립니다.즉, 로그인 프롬프트를 가져오는 대신 다이얼인 사용자는 다른 사용자가 설정한 세션(UNIX 명령 프롬프트, 텍스트 편집기 세션 등)을 볼 수 있습니다.

기존 세션에서 전화 접속 세션 열기

  • DCD용으로 구성된 모뎀 항상 높음

    1. 모뎀은 CD에서만 DCD 높음으로 재구성해야 합니다.이 작업은 일반적으로 &C1 모뎀 명령 문자열을 사용하여 수행되지만 모뎀의 정확한 구문은 모뎀 설명서를 참조하십시오.

    2. 모뎀이 연결된 액세스 서버 라인을 no exec line configuration 명령으로 구성해야 할 수도 있습니다.clear line privileged exec 명령을 사용하여 줄을 지우고, 모뎀과 역방향 텔넷 세션을 시작하고, DCD가 CD에서만 높도록 모뎀을 다시 구성합니다.

    3. 연결 끊기를 입력하여 텔넷 세션을 종료하고 exec line configuration 명령을 사용하여 액세스 서버 라인을 재구성합니다.

  • 액세스 서버 또는 라우터에서 모뎀 제어를 사용할 수 없습니다.

    1. 액세스 서버 또는 라우터에서 show line exec 명령을 사용합니다.보조 포트에 대한 출력은 Modem(모뎀) 열에 inout 또는 RIisCD를 표시해야 합니다.이는 액세스 서버 또는 라우터의 라인에서 모뎀 제어가 활성화되었음을 나타냅니다.

      show line 출력에 대한 설명은 15장의 "디버그 명령 사용" 섹션을 참조하십시오.

    2. modem inout line configuration 명령을 사용하여 모뎀 제어 회선을 구성합니다.이제 액세스 서버에서 모뎀 제어가 활성화됩니다.

    참고: 모뎀 연결에 문제가 있는 동안 modem dialin 명령 대신 modem inout 명령을 사용해야 합니다.후자 명령을 사용하면 회선에서 수신 통화만 수락할 수 있습니다.발신 통화가 거부되어 모뎀과 텔넷 세션을 설정하여 구성할 수 없습니다.modem dialin 명령을 활성화하려면 모뎀이 올바르게 작동하는지 확인한 후에만 사용합니다.

  • 잘못된 케이블 연결

    1. 모뎀과 액세스 서버 또는 라우터 간의 케이블을 확인합니다.롤드 RJ-45 케이블 및 MMOD DB-25 어댑터를 사용하여 모뎀이 액세스 서버 또는 라우터의 보조 포트에 연결되어 있는지 확인합니다.이 케이블 구성은 Cisco에서 RJ-45 포트에 대해 권장하고 지원합니다.이러한 커넥터는 일반적으로 다음과 같이 레이블이 지정됩니다.모뎀.

      RJ-45 케이블링 유형은 두 가지입니다.직선으로, 굴려.RJ-45 케이블의 양끝을 나란히 잡고 있으면 각 끝에 8개의 색상 스트립 또는 핀이 표시됩니다.색상 핀의 순서가 각 끝에서 동일하면 케이블이 직선이 됩니다.색상 순서가 각 끝에서 반전된 경우 케이블이 롤링됩니다.

      롤링된 케이블(CAB-500RJ)은 Cisco의 2500/CS500에서 표준입니다.

    2. show line exec 명령을 사용하여 케이블이 올바른지 확인합니다.이 장 15의 "Using Debug Commands" 섹션에 있는 show line 명령 출력에 대한 설명을 참조하십시오.

전화 접속 수신 모뎀이 제대로 연결 해제되지 않음

  • 모뎀에서 DTR을 감지하지 않음

    DTR 모뎀 끊기 명령 문자열을 입력합니다.이 명령은 DTR 신호가 더 이상 수신되지 않을 때 모뎀에 운송업체를 삭제하도록 지시합니다.

    Hayes 호환 모뎀에서 &D3 문자열은 모뎀에서 Hangup DTR을 구성하는 데 일반적으로 사용됩니다.이 명령의 정확한 구문은 모뎀 설명서를 참조하십시오.

  • 라우터 또는 액세스 서버에서 모뎀 제어를 사용할 수 없습니다.

    1. 액세스 서버 또는 라우터에서 show line exec 명령을 사용합니다.보조 포트의 출력은 Modem(모뎀) 열에 inout 또는 RIisCD를 표시해야 합니다.이는 액세스 서버 또는 라우터의 라인에서 모뎀 제어가 활성화되었음을 나타냅니다.

      show line 출력에 대한 설명은 15장의 "Using Debug Commands" 섹션을 참조하십시오.

    2. modem inout line configuration 명령을 사용하여 모뎀 제어 회선을 구성합니다.이제 액세스 서버에서 모뎀 제어가 활성화됩니다.

    참고: 모뎀 연결에 문제가 있는 동안 modem dialin 명령 대신 modem inout 명령을 사용해야 합니다.후자 명령을 사용하면 회선에서 수신 통화만 수락할 수 있습니다.발신 통화가 거부되어 모뎀과 텔넷 세션을 설정하여 구성할 수 없습니다.modem dialin 명령을 활성화하려면 모뎀이 올바르게 작동하는지 확인한 후에만 사용합니다.

아웃바운드 통화 문제 해결

수신 통화에 대한 문제 해결 접근 방식이 맨 아래에서 시작되는 동안 아웃바운드 연결 문제 해결은 맨 위에서 시작됩니다.추론의 일반적인 흐름은 다음과 같습니다.

  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)

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

트래픽이 다이얼 시도를 시작하지 않음

  • "흥미로운 트래픽" 정의가 없거나 잘못되었습니다.

    1. show running-config 명령을 사용하여 인터페이스가 다이얼러 그룹으로 구성되어 있고 일치하는 번호로 구성된 전역 수준 다이얼러 목록이 있는지 확인합니다.

    2. dialer-list 명령이 전체 프로토콜을 허용하거나 액세스 목록과 일치하는 트래픽을 허용하도록 구성되었는지 확인합니다.

    3. access-list가 링크를 통해 이동하는 패킷을 선언하여 관심을 가지는지 확인합니다.한 가지 유용한 테스트는 관련 액세스 목록의 번호를 사용하여 특별 권한 exec 명령 debug ip packet [list number]를 사용하는 것입니다.그런 다음 링크를 통해 ping을 시도하거나 그렇지 않으면 트래픽을 전송합니다.흥미로운 트래픽 필터가 올바르게 정의된 경우 디버그 출력에 패킷이 표시됩니다.이 테스트의 디버그 출력이 없으면 access-list가 패킷과 일치하지 않습니다.

  • 인터페이스 상태

    인터페이스가 "up/up(스푸핑)" 상태인지 확인하려면 show interfaces [interface name] 명령을 사용합니다.

    • "대기" 모드의 인터페이스

      라우터의 또 다른(기본) 인터페이스가 다이얼러 인터페이스를 백업 인터페이스로 사용하도록 구성되었습니다.또한 기본 인터페이스는 "down/down" 상태가 아니며 다이얼러 인터페이스를 스탠바이 모드에서 해제하는 데 필요합니다.또한 백업 지연을 기본 인터페이스에 구성해야 합니다. 그렇지 않으면 backup interface 명령이 적용되지 않습니다.

      다이얼러 인터페이스가 "standby"에서 "up/up(스푸핑)"으로 변경되는지 확인하려면 일반적으로 기본 인터페이스에서 케이블을 잡아당기는 것이 필요합니다.컨피그레이션 명령 종료를 사용하여 기본 인터페이스를 종료하면 기본 인터페이스가 "down/down"되지 않고 "administrator-down"으로 전환됩니다.

      또한 기본 연결이 프레임 릴레이를 통할 경우 포인트-투-포인트 직렬 하위 인터페이스에서 프레임 릴레이 컨피그레이션을 수행해야 하며 전화 회사는 "활성" 비트를 전달해야 합니다.이러한 관행은 "엔드 투 엔드 LMI"라고도 합니다.

    • 인터페이스가 "관리적으로 다운됨"

      다이얼러 인터페이스가 명령 종료로 구성되었습니다.이는 Cisco 라우터가 처음 부팅될 때 모든 인터페이스의 기본 상태입니다.이 장애를 제거하려면 interface configuration 명령 no shutdown을 사용합니다.

  • 잘못된 라우팅

    exec 명령 show ip route [a.b.c.d]를 실행합니다. 여기서 a.b.c.d는 원격 라우터의 다이얼러 인터페이스 주소입니다.원격 라우터에서 ip unnumbered를 사용하는 경우 ip unnumbered 명령에 나열된 인터페이스 주소를 사용합니다.

    출력은 다이얼러 인터페이스를 통해 원격 주소에 대한 경로를 표시해야 합니다.경로가 없는 경우 show running-config의 출력을 검토하여 고정 경로 또는 부동 고정 경로가 구성되었는지 확인합니다.

    다이얼러 인터페이스 이외의 인터페이스를 통해 경로가 있는 경우 DDR이 백업으로 사용된다는 의미입니다.라우터 컨피그레이션을 검사하여 고정 또는 부동 고정 경로가 구성되었는지 확인합니다.이 경우 라우팅을 테스트하는 가장 좋은 방법은 기본 연결을 비활성화하고 show ip route [a.b.c.d] 명령을 실행하여 라우팅 테이블에 올바른 경로가 설치되었는지 확인하는 것입니다.

    참고: 라이브 네트워크 작업 중에 이 작업을 시도하면 다이얼 이벤트가 트리거될 수 있습니다.이러한 종류의 테스트는 예약된 유지 보수 주기 중에 가장 잘 수행됩니다.

전화 걸기

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

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)
Async1 DDR: Attempting to dial 5551212

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

통화 발신 안 됨

다음과 같은 몇 가지 가능한 문제 및 권장 조치가 나와 있습니다.

  • 잘못 구성된 다이얼러 맵

    show running-config 명령을 사용하여 다이얼링 인터페이스가 하나 이상의 다이얼러 맵 문을 사용하여 구성되었는지 확인합니다. 다이얼링 인터페이스는 원격 사이트의 프로토콜 주소 및 호출된 번호를 가리킵니다.

  • 잘못 구성된 다이얼러 프로파일

    show running-config 명령을 사용하여 다이얼러 인터페이스가 다이얼러 풀 X 명령으로 구성되고 라우터의 다이얼러 인터페이스가 일치하는 다이얼러 풀 멤버 X로 구성되어 있는지 확인합니다. 다이얼러 프로필이 제대로 구성되지 않은 경우 다음과 같은 디버그 메시지가 표시될 수 있습니다. 

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

    다이얼러 문자열이 구성되었는지 확인합니다.

비동기 아웃바운드 통화 - 채팅 스크립트 작업 확인

아웃바운드 통화가 모뎀 통화인 경우 통화를 계속하려면 채팅 스크립트를 실행해야 합니다.다이얼러 맵 기반 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

채팅 스크립트 문제는 다음 세 가지 범주로 나눌 수 있습니다.

  • 구성 오류

  • 모뎀 오류

  • 연결 실패

채팅 스크립트 실패

이 목록은 디버그 채팅 프로그램의 가능한 출력 및 제안된 작업을 보여줍니다.

  • [number]에 대해 일치하는 채팅 스크립트가 없습니다.

    채팅 스크립트가 구성되지 않았습니다.하나 더

  • 채팅 스크립트 다이얼아웃이 완료되었습니다. 상태 = 연결 시간이 초과되었습니다.원격 호스트가 응답하지 않음

    모뎀이 채팅 스크립트에 응답하지 않습니다.모뎀과의 통신을 확인합니다(16장의 표 16-2 참조).

  • 시간 초과 예상:연결

    • 가능성 1:로컬 모뎀이 실제로 전화를 걸고 있지 않습니다.모뎀에 역방향 텔넷을 수행하고 수동으로 다이얼을 시작하여 모뎀에서 전화를 걸 수 있는지 확인합니다.

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

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

    • 가능성 4:모뎀 교육에 시간이 너무 오래 걸리거나 TIMEOUT 값이 너무 낮습니다.로컬 모뎀이 외부에 있는 경우 모뎀 스피커 볼륨을 켜고 교육 신호음을 들으십시오.교육이 갑자기 중단되는 경우 chat-script 명령에서 TIMEOUT 값을 늘려 보십시오.TIMEOUT이 이미 60초 이상인 경우 모뎀 교육 섹션을 참조하십시오.

ISDN 아웃바운드 통화

BRI 또는 PRI에서 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

!--- The CONNECT message is the key indicator of success. If a CONNECT is not received, !--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by !--- a cause code (see below)

*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가 수신된 위치를 나타냅니다.이를 통해 문제를 현지화할 수 있습니다.

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

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

Cause i = 0x8090 - Normal call clearing

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

원인 코드 필드

표 17-9에는 debug 명령 내에서 다음 형식으로 표시되는 ISDN 원인 코드 필드가 나와 있습니다. 

i=0x y1 y2 z1 z2 [a1 a2]

ISDN 원인 코드 필드

필드 값 설명
0배 다음 값은 16진수입니다.
y1 8 - ITU-T 표준 코딩.
y2 0—사용자 1—로컬 사용자를 서비스하는 사설 네트워크 2—로컬 사용자를 서비스하는 공용 네트워크 3—트랜짓 네트워크 4—원격 사용자를 서비스하는 공용 네트워크 5—원격 사용자를 서비스하는 사설 네트워크 7—국제 네트워크 A—인터네트워킹 포인트를 넘어 네트워크
z1 원인 값의 클래스(더 큰 16진수 숫자)입니다.가능한 값에 대한 자세한 내용은 다음 표를 참조하십시오.
z2 원인 값의 값(덜 중요한 16진수 숫자)입니다.가능한 값에 대한 자세한 내용은 다음 표를 참조하십시오.
a1 (선택 사항) 항상 8인 진단 필드입니다.
a2 (선택 사항) 다음 값 중 하나인 진단 필드0 - 알 수 없음 1 - 영구 2 - 임시

ISDN 원인 값

다음 표에는 원인 정보 요소의 가장 일반적으로 나타나는 원인 값(원인 코드의 세 번째 및 네 번째 바이트)에 대한 설명이 나와 있습니다.ISDN 코드 및 값에 대한 자세한 내용은 디버그 isdn q931 연결 해제 원인 코드 이해를 참조하십시오.

16진수 값 원인 설명
81 할당되지 않은(할당되지 않은) 번호 ISDN 번호가 올바른 형식으로 스위치에 전송되었습니다.그러나 번호가 대상 장비에 할당되지 않습니다.
90 일반 통화 지우기 일반 통화 지체가 발생했습니다.
91 사용자 사용 중 호출된 시스템은 연결 요청을 승인하지만 모든 B 채널이 사용 중이므로 통화를 수락할 수 없습니다.
92 사용자가 응답하지 않음 대상이 통화에 응답하지 않으므로 연결을 완료할 수 없습니다.
93 사용자의 응답 없음(사용자에게 알림) 대상이 연결 요청에 응답하지만 지정된 시간 내에 연결을 완료하지 못합니다.연결이 원격 끝에 있습니다.
95 통화 거부됨 대상은 통화를 수락할 수 있지만 알 수 없는 이유로 통화를 거부했습니다.
9C 잘못된 숫자 형식 대상 주소가 인식할 수 없는 형식으로 표시되었거나 대상 주소가 완전하지 않아 연결을 설정할 수 없습니다.
9F 보통, 지정되지 않음 표준 원인이 적용되지 않는 경우 일반 이벤트의 발생을 보고합니다.필요한 조치가 없습니다.
A2 사용 가능한 회선/채널 없음 통화를 받을 수 있는 적절한 채널이 없으므로 연결을 설정할 수 없습니다.
A6 네트워크 고장 네트워크가 올바르게 작동하지 않고 조건이 장기간 지속될 수 있으므로 대상에 연결할 수 없습니다.즉시 다시 연결 시도가 실패할 수 있습니다.
AC 요청된 회선/채널을 사용할 수 없음 원격 장비에서 알 수 없는 이유로 요청한 채널을 제공할 수 없습니다.일시적인 문제일 수 있습니다.
B2 요청된 협업공간이 구독되지 않음 원격 장비는 서브스크립션별로 요청된 보조 서비스를 지원합니다.장거리 서비스에 대한 참조인 경우가 많습니다.
B9 베어러 기능이 인증되지 않음 사용자가 네트워크에서 제공하는 베어러 기능을 요청했지만 사용자에게 이를 사용할 권한이 없습니다.구독 문제일 수 있습니다.
D8 호환되지 않는 대상 비 ISDN 장비에 연결하려고 시도했음을 나타냅니다.예를 들어 아날로그 회선으로 이동합니다.
E0 필수 정보 요소가 없습니다. 수신 장비에서 필수 정보 요소 중 하나가 포함되지 않은 메시지를 받았습니다.일반적으로 D-channel 오류 때문입니다.이 오류가 체계적으로 발생하면 ISDN 서비스 공급자에게 보고하십시오.
E4 잘못된 정보 요소 내용 원격 장비가 정보 요소에 잘못된 정보가 포함된 메시지를 받았습니다.일반적으로 D-channel 오류 때문입니다.

CAS 아웃바운드 통화

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

다른 DDR 상황의 경우 통화 시도가 요구되는지 확인해야 합니다.이 목적으로 디버그 다이얼러 이벤트를 사용합니다.다이얼러 작업 확인을 참조하십시오.

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

  • 디버그 모뎀

  • 디버그 모뎀 csm

  • 디버그 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# 
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을 검사해야 합니다.T1 문제 해결 정보는 15장을 참조하십시오.

PPP 문제 해결

연결의 PPP 부분 트러블슈팅은 다이얼 연결, ISDN 또는 비동기 연결이 성공적으로 설정되었음을 알 때 시작됩니다.

PPP 협상을 트러블슈팅하기 전에 성공적인 디버그 PPP 시퀀스의 모양을 이해하는 것이 중요합니다.이렇게 하면 결함이 있는 PPP 디버그 세션을 성공적으로 완료된 디버그 PPP 시퀀스와 비교하여 시간과 노력이 절약됩니다.

다음은 성공적인 PPP 시퀀스의 예입니다.출력 필드에 대한 자세한 설명은 PPP LCP 협상 세부사항을 참조하십시오. 

Montecito# 
Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up
Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25
Mar 13 10:57:15.415: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.415: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.415: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.415: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.415: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25
Mar 13 10:57:15.543: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.543: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.543: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.543: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.547: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23
Mar 13 10:57:16.919: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:16.919: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:16.919: As1 LCP:    PFC (0x0702)
Mar 13 10:57:16.919: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: State is Open
Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end
Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4
Mar 13 10:57:17.191: As1 PPP: Phase is UP
Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10
Mar 13 10:57:17.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15
Mar 13 10:57:17.319: As1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
Mar 13 10:57:17.319: As1 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
Mar 13 10:57:17.319: As1 LCP:  (0x80FD0101000F12060000000111050001)
Mar 13 10:57:17.319: As1 LCP:  (0x04)
Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10
Mar 13 10:57:17.319: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1,
 changed state to up
Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd
Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10
Mar 13 10:57:19.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10
Mar 13 10:57:19.315: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34
Mar 13 10:57:20.307: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22
Mar 13 10:57:20.543: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22
Mar 13 10:57:20.547: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: State is Open
Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1

참고: 디버그가 다른 형식으로 표시될 수 있습니다.이 예에서는 IOS 버전 11.2(8)에서 수정된 최신 PPP 디버깅 출력 형식을 보여 줍니다. 이전 버전의 IOS와 함께 PPP 디버깅의 예는 16장을 참조하십시오.

PPP LCP 협상 세부 정보

타임스탬프 설명
10:57:15.415 발송 구성 요청(O CONFREQ). NAS는 발신 PPP 컨피그레이션 요청 패킷을 클라이언트로 전송합니다.
10:57:15.543 수신 구성 승인(I CONFACK). 클라이언트는 Montecito의 PPP 요청을 승인합니다.
10:57:16.919 수신 구성 요청(I CONFREQ). 클라이언트가 콜백 프로토콜을 협상하려고 합니다.
10:57:16.919 발송 구성 거부(O CONFREJ). NAS는 콜백 옵션을 거부합니다.
10:57:17.047 수신 구성 요청(I CONFREQ). 클라이언트가 새 옵션 집합을 요청합니다.이번에는 Microsoft 콜백이 요청되지 않습니다.
10:57:17.047 발신 구성 승인(O CONFACK). NAS는 새로운 옵션 집합을 수용합니다.
10:57:17.047 PPP LCP 협상이 성공적으로 완료되었습니다.LCP 상태는 "Open"입니다. 양쪽이 (CONFECK) 상대방의 구성 요청(CONFREQ)을 승인했습니다.
10:57:17.047 - 10:57:17.191 PPP 인증이 완료되었습니다.LCP가 협상되면 인증이 시작됩니다.인증은 IP와 같은 네트워크 프로토콜이 제공되기 전에 이루어져야 합니다.양측은 LCP 중에 협상된 방법으로 인증합니다.Montecito가 CHAP를 사용하여 클라이언트를 인증하고 있습니다.
10:57:20.551 상태가 IPCP(IP Control Protocol)에 대해 열려 있습니다.IP 주소가 1.1.1.1인 IPCP 피어에 대해 경로가 협상되고 설치됩니다.

링크 제어 프로토콜

일반적으로 LCP 협상 중에 발생하는 두 가지 유형의 문제가 있습니다.

첫 번째는 한 피어가 다른 피어가 승인할 수 없거나 승인하지 않는 컨피그레이션 요청을 할 때 발생합니다.자주 발생하지만 요청자가 매개변수를 고집하는 경우 문제가 될 수 있습니다.일반적인 예는 AUTHTYPE("AuthProto"라고도 함)을 협상할 때 발생합니다. 예를 들어, 많은 액세스 서버가 인증에 CHAP만 허용하도록 구성되어 있습니다.발신자가 PAP 인증만 수행하도록 구성된 경우, 한 피어 또는 다른 피어 중 하나가 연결을 끊어질 때까지 CONFREQ 및 CONNAK가 교환됩니다. 

BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
...
...

LCP의 두 번째 문제 유형은 아래 예와 같이 하나 또는 두 피어에서 아웃바운드 CONFREQ만 표시되는 경우입니다.이는 일반적으로 하위 레이어에서 속도 불일치라고 하는 결과입니다.이 상태는 비동기 또는 ISDN DDR에서 발생할 수 있습니다. 

Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open  
Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25  
Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:57:59.768: As5 LCP: PFC (0x0702)
Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) 
Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 
Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:01.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). 
Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 
Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:03.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) 
Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 

!--- This repeats every two seconds until:

Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 
Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:19.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802)  
Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR

연결이 비동기인 경우 라우터와 모뎀의 속도 불일치가 발생할 수 있습니다.이는 일반적으로 모뎀의 DTE 속도를 TTY 회선의 구성된 속도로 잠그지 못했기 때문입니다.이 문제는 둘 중 하나 또는 둘 다에서 발견될 수 있으므로 둘 다 확인하십시오.이 장 앞에서 모뎀에서 데이터를 보내거나 받을 수 없음을 참조하십시오.

연결이 ISDN을 통해 연결되었을 때 증상이 나타나면 한 피어가 56K로 연결되고 다른 피어는 64K로 연결되었을 가능성이 높습니다.이러한 상황은 드물지만 실제로 발생합니다.문제는 한 명 또는 두 명의 동료일 수도 있고, 전화 회사일 수도 있습니다.debug isdn q931을 사용하고 각 피어의 SETUP 메시지를 검사합니다.한 피어에서 전송된 베어러 기능은 다른 피어에서 수신한 SETUP 메시지에 표시된 베어러 기능과 일치해야 합니다.가능한 해결 방법으로, dialer speed(56K 또는 64K)를 interface level 명령 다이얼러 맵 또는 map-class에 구성된 명령 다이얼러 isdn speed에서 구성합니다. 

*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

이러한 상황은 Cisco TAC에 전화를 걸 수 있는 상황입니다.TAC에 전화를 걸기 전에 두 피어에서 다음 출력을 수집합니다.

  • show running-config

  • 버전 표시

  • 디버그 isdn q931

  • 디버그 isdn 이벤트

  • 디버그 ppp 협상

인증

PPP에 장애가 발생한 가장 일반적인 이유는 인증 실패입니다.잘못 구성되었거나 일치하지 않는 사용자 이름과 비밀번호는 디버그 출력에서 오류 메시지를 생성합니다.

다음 예는 사용자 이름 Goleta에 이 사용자에 대해 구성된 로컬 사용자 이름이 없는 NAS에 전화를 걸 수 있는 권한이 없음을 보여줍니다.문제를 해결하려면 username name password password 명령을 사용하여 NAS 로컬 AAA 데이터베이스에 사용자 이름 "Goleta"를 추가합니다. 

Mar 13 11:01:42.399: As2 LCP: State is Open
Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response.  Username Goleta not found
Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure"
Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING

다음 예는 사용자 이름 "Goleta"가 NAS에 구성되어 있음을 보여줍니다.그러나 비밀번호를 비교하지 못했습니다.이 문제를 해결하려면 username name password password password 명령을 사용하여 Goleta에 대한 올바른 로그인 비밀번호를 지정합니다. 

Mar 13 11:04:06.843: As3 LCP: State is Open
Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed"
Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING

PAP 인증에 대한 자세한 내용은 PAP(PPP 비밀번호 인증 프로토콜) 구성 및 문제 해결을 참조하십시오.

네트워크 제어 프로토콜

피어가 필요한 인증을 성공적으로 수행한 후 협상은 NCP 단계로 이동합니다.두 피어가 모두 올바르게 구성된 경우 NCP 협상은 클라이언트 PC가 NAS에 다이얼링 및 협상하는 예를 보여주는 다음 예와 같이 보일 수 있습니다. 

solvang# show debug
Generic IP:
IP peer address activity debugging is on
PPP:
PPP protocol negotiation debugging is on

*Mar  1 21:35:04.186: As4 PPP: Phase is UP
*Mar  1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
*Mar  1 21:35:04.194: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28
*Mar  1 21:35:04.282: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.286: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:04.290: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:04.298: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar  1 21:35:04.310: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15
*Mar  1 21:35:04.318: As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
*Mar  1 21:35:04.318: As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
*Mar  1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
*Mar  1 21:35:04.326: As4 LCP:  (0x80FD0101000F12060000000111050001)
*Mar  1 21:35:04.330: As4 LCP:  (0x04)
*Mar  1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 21:35:04.338: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4,
 changed state to up
*Mar  1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.278: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:07.282: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:07.286: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.298: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.302: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.310: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.430: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.434: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.442: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2
*Mar  1 21:35:07.450: ip_get_pool: As4: using pool default
*Mar  1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2
*Mar  1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
*Mar  1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.462: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.466: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.474: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.478: As4 IPCP: State is Open
*Mar  1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2

PPP NCP 협상 세부 정보

타임스탬프 설명
21:35:04.190 발송 구성 요청(O CONFREQ). NAS는 IP 주소를 포함하는 발신 PPP 구성 요청 패킷을 피어로 전송합니다.
21:35:04.282 수신 CONFREQ.피어가 VJ 헤더 압축을 수행하도록 요청합니다.자체 IP 주소는 물론 기본 및 보조 DNS 서버의 주소도 필요합니다.
21:35:04.306 CONFREJ(Outbound Config-Reject).VJ 헤더 압축이 거부되었습니다.
21:35:04.314 - 21:35:04.330 피어가 압축 제어 프로토콜을 수행하도록 요청을 보냅니다.전체 프로토콜은 NAS에서 PROTREJ 메시지를 통해 거부됩니다.피어가 CCP를 재시도하지 않아야 합니다(그리고 시도하지 않아야 함).
21:35:04.334 피어는 NAS의 IP 주소를 CONFACK로 인식합니다.
21:35:07.274 수신 CONFREQ.피어는 더 이상 VJ 헤더 압축을 수행하도록 요청하지 않지만, 기본 및 보조 DNS 서버의 주소는 물론 자체 IP 주소가 필요합니다.
21:35:07.294 NAS는 피어가 사용할 주소와 기본 및 보조 DNS 서버의 주소를 포함하는 CONNAK를 전송합니다.
21:35:07.426 피어가 주소를 NAS로 다시 전송합니다.주소가 제대로 수신되었는지 확인하는 시도.
21:35:07.458 NAS는 CONFACK를 통해 주소를 인식합니다.
21:35:07.478 CONFACK를 발급한 연결의 각 쪽이 협상을 완료합니다.NAS의 show interfaces Async4 명령에 "IPCP:열기".
21:35:07.490 원격 피어에 대한 호스트 경로가 NAS의 라우팅 테이블에 설치됩니다.

피어가 동시에 둘 이상의 레이어 3 프로토콜을 협상할 수 있습니다.예를 들어, IP 및 IPX가 협상되는 것을 보는 것은 일반적이지 않습니다.또한 한 프로토콜이 성공적으로 협상하는 동안 다른 프로토콜이 협상을 수행하지 못할 수도 있습니다.

NCP 문제 해결

NCP 협상 중에 발생하는 모든 문제는 일반적으로 협상 피어의 컨피그레이션으로 추적될 수 있습니다.NCP 단계 중에 PPP 협상이 실패할 경우 다음 단계를 참조하십시오.

  1. 인터페이스 프로토콜 컨피그레이션 확인

    특권 exec 명령 show running-config의 출력을 검토합니다.연결을 통해 실행할 프로토콜을 지원하도록 인터페이스가 구성되었는지 확인합니다.

  2. 인터페이스 주소 확인

    해당 인터페이스에 주소가 구성되어 있는지 확인합니다.ip unnumbered [interface-name] 또는 ipx ppp-client 루프백 [number]을(를) 사용하는 경우 참조된 인터페이스가 주소로 구성되어 있는지 확인합니다.

  3. 클라이언트 주소 가용성 확인

    NAS가 발신자에게 IP 주소를 발행하도록 되어 있는 경우 해당 주소를 사용할 수 있는지 확인합니다.발신자에게 전달할 IP 주소는 다음 방법 중 하나를 통해 얻을 수 있습니다.

    • 인터페이스에서 로컬로 구성합니다.명령 피어 기본 ip 주소 a.b.c.d에 대한 인터페이스 컨피그레이션을 확인합니다.실제로 이 메서드는 비동기(group-async가 아님) 인터페이스와 같이 단일 호출자의 연결을 수락하는 인터페이스에서만 사용해야 합니다.

    • NAS에 로컬로 구성된 주소 풀입니다.인터페이스에는 명령 피어 기본 ip 주소 풀 [pool-name]이 있어야 합니다.또한 풀을 시스템 수준에서 ip local pool [pool-name] [first-address] [last-address] 명령을 사용하여 정의해야 합니다.풀에 정의된 주소 범위는 NAS가 지원하는 만큼 동시에 연결된 발신자를 수용할 만큼 충분히 커야 합니다.

    • DHCP 서버.NAS 인터페이스는 명령 피어 기본 ip 주소 dhcp로 구성해야 합니다.또한 NAS는 전역 구성 명령 ip dhcp-server [address]를 사용하여 DHCP 서버를 가리키도록 구성해야 합니다.

    • AAA.권한 부여를 위해 TACACS+ 또는 RADIUS를 사용하는 경우, 발신자가 연결될 때마다 특정 IP 주소를 지정된 발신자에게 전달하도록 AAA 서버를 구성할 수 있습니다.자세한 내용은 16장을 참조하십시오.

  4. 서버 주소 구성 확인

    BOOTP 요청에 대한 응답으로 도메인 이름 서버 또는 Windows NT 서버의 구성된 주소를 반환하려면 전역 수준 명령 async-bootp dns-server [address] 및 async-bootp nbns-server [address]가 구성되었는지 확인합니다.

    참고: 명령 async-bootp subnet-mask [mask]를 NAS에서 구성할 수 있지만, 서브넷 마스크는 NAS와 PPP 다이얼인 클라이언트 PC 간에 협상되지 않습니다.포인트 투 포인트 연결의 특성 때문에 클라이언트는 IP를 협상하는 동안 학습된 NAS의 IP 주소를 기본 게이트웨이로 자동으로 사용합니다.해당 지점 간 환경에서는 서브넷 마스크가 필요하지 않습니다.PC는 대상 주소가 로컬 주소와 일치하지 않을 경우 패킷이 항상 PPP 링크를 통해 도달하는 기본 게이트웨이(NAS)로 전달되어야 함을 알고 있습니다.

Cisco Systems TAC 팀에 전화하기 전

Cisco Systems TAC(Technical Assistance Center)에 전화를 걸기 전에 이 장을 읽고 시스템 문제에 대해 제안된 작업을 완료해야 합니다.

또한 다음을 수행하고 결과를 문서화하여 더 효과적으로 지원할 수 있습니다.

모든 문제에 대해 show running-config 및 show version의 출력을 수집합니다.명령 서비스 타임스탬프 디버그 datetime msec이 컨피그레이션에 있는지 확인합니다.

DDR 문제의 경우 다음을 수집합니다.

  • 전화 걸기 맵 표시

  • 디버그 다이얼러

  • 디버그 ppp 협상

  • 디버그 ppp 인증

ISDN이 관련된 경우 다음을 수집합니다.

  • isdn 상태 표시

  • 디버그 isdn q931

  • 디버그 isdn 이벤트

모뎀이 관련된 경우 다음을 수집합니다.

  • 라인 표시

  • [x] 행 표시

  • 모뎀 표시(통합 모뎀이 포함된 경우)

  • 모뎀 버전 표시(통합 모뎀이 포함된 경우)

  • 디버그 모뎀

  • 모뎀 csm 디버그(통합 모뎀이 포함된 경우)

  • 디버그 채팅(DDR 시나리오의 경우)

T1s 또는 PRI가 관련된 경우 다음을 수집합니다.

  • 컨트롤러 t1 표시

관련 정보

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

Feedback피드백

지원 문의

이 문서가 적용되는 제품