Cisco DSL 라우터 구성 및 문제 해결 가이드 - PPPoA 문제 해결

다운로드 옵션

PDF (252.3 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (89.5 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (86.6 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2006년 10월 2일

문서 ID:71115

편견 없는 언어

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

이 번역에 관하여

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

소개

DSL(Digital Subscriber Line) 연결이 제대로 작동하지 않는 이유는 여러 가지가 있습니다.이 문서의 목적은 장애의 원인을 파악하고 복구하는 것입니다.첫 번째 문제 해결 단계는 어떤 ADSL(Asynchronous Digital Subscriber Line) 서비스가 실패하는지 확인하는 것입니다.장애가 발생할 수 있는 레이어는 세 가지입니다.

레이어 1 - ISP 디지털 가입자 회선 액세스 멀티플렉서(DSL)에 대한 DSL 물리적 연결
Layer 2.1 - ATM 연결
레이어 2.2 - PPPoA(Point-to-Point Protocol over ATM), PPPoE(Point-to-Point Protocol over Ethernet), RFC1483 브리징 또는 RFC1483 라우팅
레이어 3 - IP

트러블슈팅을 시작할 레이어를 결정하는 가장 쉬운 방법은 show ip interface brief 명령을 실행하는 것입니다.이 명령의 출력은 컨피그레이션에 따라 약간 다릅니다.

827-ESC#show ip interface brief
Interface     IP-Address     OK?     Method     Status     Protocol
ATM0          unassigned     YES     manual 	    up         up
ATM0.1        unassigned     YES     unset  	    up         up
Ethernet0     10.10.10.1     YES     manual      up         up

ATM0 및 ATM0.1의 상태가 작동 중이고 프로토콜이 작동 중인 경우 레이어 2에서 트러블슈팅을 시작합니다.

ATM 인터페이스가 다운되었거나 계속 위로 올라오고 내려가면(작동 및 작동 안 함) 레이어 1에서 트러블슈팅을 시작합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

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

표기 규칙

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

레이어 1 문제

Cisco DSL Router의 전면 패널에 있는 캐리어 탐지(CD) 표시등이 켜져 있거나 꺼져 있습니까?

CD 표시등이 켜져 있으면 이 문서의 레이어 2 문제 섹션으로 이동합니다.

CD 표시등이 꺼진 경우 다음 질문을 계속 진행합니다.

ISP에서 Alcatel 칩셋을 지원하는 DSLAM을 사용하고 있습니까?

ISP에서 이 정보를 확인합니다.

Cisco DSL 라우터 뒷면의 DSL 포트가 DSL 벽면 잭에 연결되어 있습니까?

DSL 포트가 DSL 벽면 잭에 연결되지 않은 경우 4핀 또는 6핀 RJ-11 케이블을 사용하여 벽면에 포트를 연결합니다.이것은 표준 전화 케이블입니다.

ATM 인터페이스가 관리적으로 다운 상태입니까?

ATM0 인터페이스가 관리 목적으로 다운되었는지 확인하기 위해 라우터에서 enable 모드에서 이 명령을 실행합니다.

Router#show interface atm 0
ATM0 is administratively down, line protocol is down
<... snipped ...>

ATM0 인터페이스 상태가 관리 목적으로 다운된 경우 ATM0 인터페이스에서 no shutdown 명령을 실행합니다.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#no shut
Router(config-if)#end
Router#write memory

케이블 핀아웃이 맞습니까?

ATM0 인터페이스 상태가 다운 및 다운인 경우 라우터에 ADSL 회선에 캐리어가 표시되지 않습니다.이는 일반적으로 두 가지 문제 중 하나를 나타냅니다.

DSL 벽면 잭의 활성 핀이 잘못되었습니다.
ISP에서 이 벽면 잭에 DSL 서비스를 설정하지 않았습니다.

Cisco DSL Router xDSL 포트 핀아웃

RJ-11 커넥터는 표준 RJ-11 6핀 모듈형 잭을 통해 외부 미디어에 xDSL 연결을 제공합니다.

핀	설명
3	XDSL_팁
4	XDSL_링

참고: Cisco 1417은 표준 RJ-11 6핀 모듈형 잭에 핀 2와 5를 사용합니다.

ATM0 인터페이스가 다운 및 다운되었는지 확인하려면 라우터의 enable 모드에서 show interface atm 0 명령을 실행합니다.

Router#show interface atm 0
ATM0 is down, line protocol is down
<... snipped ...>

ATM 인터페이스가 다운되어 관리 목적으로 다운되지 않은 경우 DSL 벽면 잭의 핀아웃을 확인합니다.DSL 라우터는 표준 RJ-11(4핀 또는 6핀) 케이블을 사용하여 벽면 잭에 ADSL 연결을 제공합니다.RJ-11 케이블의 핀 가운데 쌍은 ADSL 신호(6핀 케이블의 핀 3과 4 또는 4핀 케이블의 핀 2와 3)를 전달하는 데 사용됩니다. 핀 2와 5를 사용하는 Cisco 1417에는 적용되지 않습니다.

벽면 잭에 오른쪽 핀이 있고 ATM0 인터페이스가 계속 다운 및 다운된 경우 DSL 포트와 벽면 잭 사이에 RJ-11 케이블을 교체합니다.RJ-11 케이블을 교체한 후에도 인터페이스가 계속 다운된 경우 ISP에 문의하고 ISP에서 사용하는 벽면 잭에서 ADSL 서비스가 활성화되었는지 확인합니다.

벽면 잭의 핀이 활성 상태인지 확실하지 않으면 ISP에 문의하십시오.

Cisco 827을 DSL CPE(Customer Premises Equipment)로 사용하는 경우, Cisco 827에 맞는 전원 공급 장치가 있습니까?

DSL 케이블이 정상이고 올바른 핀아웃이 있는지 확인한 경우 다음 단계는 827에 맞는 전원 공급 장치를 갖추는 것입니다.

참고: 827은 다른 Cisco 800 Series 라우터와 동일한 전원 공급 장치를 사용하지 않습니다.

올바른 전원 공급 장치가 있는지 확인하려면 전원 어댑터 뒷면에서 출력 +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A 및 -71V 0.12A를 확인합니다.전원 공급 장치에 +12V 및 -12V 피드가 없는 경우 다른 Cisco 800 Series 라우터용이며 827에서 작동하지 않습니다. 잘못된 전원 공급 장치를 사용하는 경우 Cisco 827의 전원이 켜지지만 ISP DSLAM에 대한 교육(연결)이 불가능합니다.

DSL 운영 모드가 정확합니까?

레이어 1 문제 해결 절차의 이 시점까지 모든 것이 올바르면 다음 단계는 올바른 DSL 운영 모드를 사용하는 것입니다.ISP에서 사용하는 DMT 기술을 잘 모르는 경우 dsl 운영 모드 auto를 사용하는 것이 좋습니다.다음은 운영 모드 자동 탐지를 구성하는 명령입니다.

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#dsl operating-mode auto
Router(config-if)#end
Router#write memory

회로가 올바르게 테스트/프로비저닝되었습니까?

ISP 또는 전화 회사로부터 이 정보를 얻습니다.

레이어 2 문제

올바른 PVC(Permanent Virtual Circuit) 값(VPI/VCI)이 있습니까?

라우터에 올바른 VPI/VCI(가상 경로 식별자/가상 회로 식별자) 값이 구성되어 있는지 확인하려면 다음 단계를 완료하십시오.

Cisco IOS® 소프트웨어 버전을 확인합니다.

중요:Cisco IOS Software 릴리스 12.1(1)XB에서는 작동하지 않습니다.

Router#show version 

!--- Used to determine your Cisco IOS version.


Cisco Internetwork Operating System Software
IOS (tm) C820 Software (C820-OSY656I-M), Version 12.1(3)XG3, 
EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

!--- The two lines immediately preceding appear on one line on the router.
 
TAC:Home:SW:IOS:Specials for info
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 20-Dec-00 16:44 by detang
Image text-base: 0x80013170, data-base: 0x80725044
<... snipped ...>

디버그 로깅을 위해 라우터를 구성합니다.

Router#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#logging console
Router(config)#logging buffer
Router(config)#service timestamp debug datetime msec
Router(config)#service timestamp log datetime msec
Router(config)#end
Router#write memory
Building configuration...
[OK]
Router#terminal monitor

라우터에서 디버깅을 활성화합니다.

Router#debug atm events 
ATM events debugging is on
Router#
2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EF74 length=52
2d18h: Data Cell received on vpi = 8 vci = 35

!--- Your VPI/VCI.

2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EEC0 length=52
2d18h: Data Cell received on vpi = 8 vci = 35
2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EECC length=52
2d18h: Data Cell received on vpi = 8 vci = 35
2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EED8 length=52
2d18h: Data Cell received on vpi = 8 vci = 35

Cisco DSL 라우터에서 실행 중인 ATM 이벤트를 디버깅해야 합니다. 그런 다음 작동하는 인터넷 연결로 이동하여 ISP가 정적으로 할당한 IP 주소를 ping하기 시작합니다.

Cisco DSL 라우터에서 이 IP 주소를 구성했는지 여부는 중요하지 않습니다.중요한 것은 ATM 인터페이스가 작동/작동하며 ISP에서 제공한 IP 주소를 ping하는 것입니다.ping 테스트 후 예상 출력이 표시되지 않으면 ISP에 지원을 요청하십시오.
라우터에서 디버깅을 비활성화합니다.

<< 60초 대기 >>
```
Router#undebug all 

!--- Turn off the debug events.


All possible debugging has been turned off.
```
VPI/VCI 값을 확인한 다음 필요한 컨피그레이션을 변경합니다.

디버깅 60초 동안 출력이 표시되지 않으면 ISP에 문의하십시오.

ISP에서 데이터를 받고 있습니까?

올바른 PVC 값이 있는 경우 다음 단계는 ISP와 PPP를 협상하려고 시도하는지 확인하는 것입니다.이렇게 하려면 show interface atm0 명령을 실행하고 입력 및 출력 패킷을 확인합니다.

Router#show interface atm0
ATM0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5, PVC mode
24 maximum active VCs, 256 VCS per VP, 1 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5 bits/sec, 0 packets/sec
5 minute output rate 7 bits/sec, 0 packets/sec
100 packets input, 5600 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
250 packets output, 1400 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out

패킷 카운터가 증가하면 ISP에서 PPP 협상 패킷을 받아야 합니다.그렇지 않은 경우 ISP에 문의하십시오.

출력 바인딩된 카운터가 증가하면 PPP 협상 패킷을 보내야 합니다.그렇지 않은 경우 라우터의 컨피그레이션을 확인합니다.PPP가 올바르게 구성된 경우 PPP 협상 패킷은 ATM0 인터페이스에서 지속적으로 전송됩니다.

패킷이 양방향으로 증가하면 이 문서의 문제 해결 단계를 계속 진행합니다.

PPP가 제대로 협상하고 있습니까?

레이어 1이 작동되고 올바른 VPI/VCI가 있는 경우 다음 단계는 PPP가 제대로 작동하는지 확인하는 것입니다.이를 위해서는 Cisco DSL 라우터에서 일련의 debug 명령을 실행하고 출력을 해석해야 합니다.사용하는 기본 디버그는 디버그 ppp 협상입니다.이 명령 출력은 성공적인 PPP 협상의 예입니다.

Router#debug ppp negotiation

PPP protocol negotiation debugging is on

Router#
2w3d: Vi1 PPP: No remote authentication for call-out
2w3d: Vi1 PPP: Phase is ESTABLISHING
2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15
2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305)
2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A)
2w3d: Di1 IPCP: Remove route to 20.20.2.1
2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: State is Open
2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer
2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2"
2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John"
2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4
2w3d: Vi1 PPP: Phase is UP
2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10
2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2
2w3d: Di1 IPCP: Install route to 20.20.2.1
Router#

PPP 협상에는 4가지 주요 실패 지점이 있습니다.

원격 장치(ISP)로부터 응답이 없음
LCP(Link Control Protocol)가 열리지 않음
인증 실패
IPCP(IP Control Protocol) 실패

ISP로부터 응답이 없음

인바운드 방향의 ATM0 인터페이스에서 패킷이 증가하는지 이미 확인했으므로 ISP에서 응답하지 않는 것은 문제가 되지 않습니다.그러나 인바운드 방향으로 ATM0에서 패킷이 증가하며 디버그 ppp 협상을 실행할 때 이를 수신하면 ISP에 문의하여 패킷이 Cisco DSL 라우터로 전송되는지 확인합니다.

Router#debug ppp negotiation
*Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout
*Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out
*Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10 

!--- "O" specifies an outbound packet

*Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10 

!--- "O" specifies an outbound packet

*Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10 
*Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10
*Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10
*Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10
*Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent 
*Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10 

!--- "O" specifies an outbound packet

*Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
Router#undebug all

이 출력에는 아웃바운드 패킷인 O 패킷만 있습니다.PPP를 성공적으로 협상하려면 전송된 각 O 패킷에 대해 ISP에서 I 인바운드 패킷이 있어야 합니다.패킷이 인바운드을 증가하지만 I 패킷이 표시되지 않으면 ISP에 문의하여 Cisco DSL 라우터로 전송되는 패킷을 확인하십시오.

LCP가 열리지 않음

LCP가 열리지 않는 이유는 일반적으로 PPP 옵션이 일치하지 않기 때문입니다.이러한 불일치는 Cisco DSL 라우터에 ISP에서 지원하지 않는 PPP 매개변수가 구성되어 있거나 ISP에 Cisco DSL 라우터가 지원하지 않는 매개변수가 구성되어 있는 경우 발생합니다.이 출력은 PPP 옵션 불일치의 예를 보여줍니다.

Router#debug ppp negotiation
*Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout
*Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] 
*Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out 
*Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14
*Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9

!--- PPP option reject

*Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10
*Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14
*Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 

!--- PPP option reject

*Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) 

!--- PPP option that is rejected

*Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14
*Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
Router#undebug all

I 패킷이든 O 패킷이든 Configure-Negative-Acknowledge(CONNAK)는 PPP 컨피그레이션 불일치를 나타냅니다.이는 PPP 연결의 한 쪽이 다른 쪽이 수행할 수 없거나 수행하도록 구성되지 않은 PPP 옵션을 요청하는 것을 의미합니다.Cisco DSL 라우터가 CONNAK("O CONNAK"로 표시됨)를 전송하면 Cisco DSL 라우터는 ISP에서 전송하는 옵션에 대해 수행할 수 없거나 구성되지 않습니다.ISP에서 CONNAK을 전송하는 경우("I CONNAK"로 표시됨), ISP에서 수행하지 않을 옵션을 Cisco DSL 라우터에 구성했습니다.

CONNAK 뒤의 줄에서는 거부된 옵션에 대해 설명합니다.이 예제 출력에서 옵션은 CHAP(Challenge Handshake Authentication Protocol)이지만 모든 옵션일 수 있습니다.PPP 옵션을 구성할 수 있는 Cisco DSL 라우터의 유일한 위치는 인터페이스 다이얼러 1입니다. 인터페이스 다이얼러 1 컨피그레이션을 보려면 show run interface dialer 1 명령을 실행하십시오.

ISP에서 I CONNAK을 보내는 경우 인터페이스 다이얼러 1 아래의 명령을 찾아 CONNAK 뒤에 있는 라인과 일치하는 명령을 찾아 제거합니다.Cisco DSL 라우터가 O CONNAK를 전송하는 경우, 인터페이스 다이얼러 1에 명령을 추가하여 ISP와 PPP를 올바르게 협상합니다.패킷을 전송하는 라우터의 경우 Cisco DSL 라우터에서 어떤 명령을 활성화해야 하는지 확인하기 위해 Cisco Support에 문의해야 할 수 있습니다.

인증 실패

ISP에서 PPP 사용자 이름 또는 비밀번호를 인증할 수 없을 때 인증 오류가 발생합니다.이러한 상황이 발생할 수 있는 두 가지 시나리오가 있습니다.첫 번째 시나리오는 라우터를 제대로 구성하지 않을 때 발생하는 인증 유형 불일치입니다.PAP(Password Authentication Protocol) 및 CHAP 인증 유형 모두에 대해 이 문서 계정에 나열된 모든 인증 컨피그레이션입니다.구성 유연성을 위해 CHAP와 PAP를 모두 구성해야 합니다.두 가지 구성이 모두 구성되지 않은 경우 다음 예와 같은 debug ppp 명령의 출력을 볼 수 있습니다.

Router#debug ppp negotiation
00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15 
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Sends CHAP requests

00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)
00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14
00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023)

!--- Receives PAP requests from the service provider

00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8
Router#undebug all

또는

Router#debug ppp negotiation
00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15
00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Receives CHAP requests from the service provider

00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC)
00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14
00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023) 

!--- Sends out PAP requests

Router#undebug all

!--- Turns off ppp debug.

두 인증 불일치 문제를 모두 수정하려면 적절한 PPPoA 구현 옵션 컨피그레이션을 참조하고 PPP 인증을 다시 구성하십시오.

두 번째 인증 문제 시나리오는 잘못된 PAP 사용자 이름 또는 비밀번호입니다.이것이 문제인지 확인하려면 디버그 ppp 협상 명령을 실행합니다.라우터가 CHAP와 PAP에 모두 구성되어 있다고 가정할 때, 이 가이드의 앞에서 설명한 컨피그레이션에 따라 ISP에서 PAP 인증을 사용하지 않을 수 있습니다.

ISP에서 사용하는 인증을 확인하려면 ISP에서 사용자에게 전송한 I CONFREQ 패킷의 옵션을 확인합니다.이 패킷 다음에 AuthProto PAP라는 옵션이 있으면 PAP를 사용합니다.I CONFREQ에 AuthProto CHAP라는 옵션이 있으면 CHAP를 사용하고 있으며 내 CHAP 사용자 이름과 암호가 올바른지 어떻게 알 수 있습니까? 로 진행해야 합니다.

PAP 사용자 이름 및 비밀번호가 정확한지 어떻게 알 수 있습니까?

ISP에서 PAP를 사용하는지 확인한 후 debug ppp negotiation 명령을 실행하여 PAP 사용자 이름 및 비밀번호가 올바른지 확인합니다.

Router#debug ppp negotiation 
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" 

!--- "cisco" is the PAP username configured on this DSL Router.

*Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]

PAP 인증 문제가 있는 경우 LCP 상태가 Open(열기)으로 이동하는 것을 확인해야 합니다.LCP 상태 변경 바로 다음에 PPP가 인증 단계로 들어가는 것을 볼 수 있습니다.다음 두 행 중 하나에 I AUTH-NAK가 포함되어 있는 경우 PAP 사용자 이름 또는 PAP 암호가 잘못되었습니다.이때 이 명령 시퀀스를 사용하여 PAP 사용자 이름 및 비밀번호를 재구성해야 합니다.PAP 사용자 이름과 비밀번호는 대/소문자를 구분합니다.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp pap sent-username 
      
      
        password 
        
      
Router(config-if)#end
Router#write memory

CHAP 사용자 이름과 암호가 올바른지 어떻게 알 수 있습니까?

ISP에서 CHAP를 사용하는지 확인한 후 debug ppp negotiation 명령을 실행하여 CHAP 사용자 이름과 암호가 올바른지 확인합니다.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"  

!--- "cisco" is the CHAP username configured on this DSL Router.

*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all

CHAP 인증 문제가 있는 경우 LCP 상태가 Open(열기)으로 이동하는 것을 확인해야 합니다.LCP 상태 변경 바로 다음에 PPP가 인증 단계로 들어가는 것을 볼 수 있습니다.이 시점에서는 일련의 CHAP 회선을 볼 수 있습니다.마지막 행에 I FAILURE 가 표시되면 잘못된 CHAP 사용자 이름 및 비밀번호를 갖게 됩니다.CHAP 사용자 이름 및 암호를 수정하려면 이 명령 순서를 사용하십시오.사용자 이름과 비밀번호는 대/소문자를 구분합니다.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname 
      
       
Router(config-if)#ppp chap password 
      
      
Router(config-if)#end
Router#write memory

PPP 인증이 성공한 시점을 어떻게 알 수 있습니까?

다음은 성공한 CHAP 협상을 보여주는 예입니다.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:30:09.335: Vi1 LCP: State is Open
*Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3"
*Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 03:30:09.383: Vi1 CHAP: Using default password
*Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco"
*Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4

!--- CHAP negotiation was a success.

*Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load] 
<... snipped ...>
Router#undebug all

이 예에서는 성공한 PAP 협상을 보여 줍니다.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] 

!--- PAP negotiation was a success.

<... snipped ...>
Router#undebug all