Cisco DSL 라우터 구성 및 문제 해결 가이드 - PPPoE:PPPoE 클라이언트 문제 해결용 DSL 라우터
목차
소개
DSL(Digital Subscriber Line) 연결이 제대로 작동하지 않는 이유는 여러 가지가 있습니다.이 문서의 목적은 장애의 원인을 파악하고 복구하는 것입니다.첫 번째 문제 해결 단계는 어떤 ADSL(Asynchronous Digital Subscriber Line) 서비스가 실패하는지 확인하는 것입니다.장애가 발생할 수 있는 레이어는 세 가지입니다.
-
레이어 1 - ISP의 DSL(Digital Subscriber Line Access Multiplexer)에 대한 물리적 연결
-
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_링 |
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)를 전달하는 데 사용됩니다.
벽면 잭에 오른쪽 핀이 있고 ATM0 인터페이스가 계속 다운 및 다운된 경우 DSL 포트와 벽면 잭 사이에 RJ-11 케이블을 교체합니다.RJ-11 케이블을 교체한 후에도 인터페이스가 계속 다운된 경우 ISP에 문의하고 ISP에서 사용하는 벽면 잭에서 DSL 서비스가 활성화되었는지 확인합니다.
벽면 잭의 핀이 활성 상태인지 확실하지 않으면 ISP에 문의하십시오.
Cisco 827에 맞는 전원 공급 장치가 있습니까?
DSL 케이블이 정상이고 올바른 핀아웃이 있는지 확인한 경우 다음 단계는 827에 맞는 전원 공급 장치를 갖추는 것입니다.
참고: 827은 다른 800 시리즈 라우터와 동일한 전원 공급 장치를 사용하지 않습니다.
올바른 전원 공급 장치가 있는지 확인하려면 전원 어댑터 뒷면에서 출력 +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A 및 -71V 0.12A를 확인합니다.전원 공급 장치에 +12V 및 -12V 피드가 없는 경우 다른 Cisco 800 시리즈 라우터용이며 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 값(VPI/VCI)이 있습니까?
PPPoE 구축에서는 PVC(Permanent Virtual Circuit) VPI/VCI(virtual channel identifier) 값을 동적으로 검색하는 쉬운 방법이 없습니다.PVC 값을 모르는 경우 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에서 PPPoE 협상 패킷을 받아야 합니다.그렇지 않은 경우 ISP에 문의하십시오.
출력 바인딩된 카운터가 증가하면 PPPoE 협상 패킷을 보내야 합니다.그렇지 않은 경우 라우터의 컨피그레이션을 확인합니다.PPP가 올바르게 구성된 경우 PPP 협상 패킷은 ATM0 인터페이스에서 지속적으로 전송됩니다.
패킷이 아웃바운드 방향으로만 증가하면 이 문서의 문제 해결 단계를 계속 진행합니다.
PPPoE 세션이 시작됩니까?
PPPoE는 두 단계로 실행됩니다.첫 번째 단계는 PPPoE 세션 설정이고 두 번째 단계는 PPP 협상입니다.표준 PPP 매개변수를 협상하기 전에 PPPoE를 설정해야 합니다.활성 PPPoE 세션이 있는지 확인하는 가장 쉬운 방법은 show vpdn 명령을 실행하는 것입니다.
Router#show vpdn %No active L2TP tunnels %No active L2F tunnels %No active PPTP tunnels PPPoE Tunnel and Session Information Total tunnels 1 sessions 1 PPPoE Tunnel Information Session count: 1 PPPoE Session Information SID RemMAC LocMAC Intf Vast OIntf VP/VC 0 0000.0000.0000 0000.0000.0000 UNKN ATM0 8/35
이 예에서는 활성 상태인 PPPoE 세션이 없습니다.이는 SID의 0과 RemMAC 및 LocMAC0000.0000.0000으로 표시됩니다. 이 상태이면 다음 섹션으로 진행합니다.
성공적으로 협상된 PPPoE 세션은 다음과 같습니다.
Router#show vpdn %No active L2TP tunnels %No active L2F tunnels PPPoE Tunnel and Session Information Total tunnels 1 sessions 1 PPPoE Tunnel Information Session count: 1 PPPoE Session Information SID RemMAC LocMAC Intf Vast OIntf VP/VC 1 0050.7359.35b7 0001.96a4.84ac Vi1 UP ATM0 8/35
이 예에서는 SID가 0이 아닌 숫자이며 RemMAC 및 LocMAC 필드가 모두 채워져 있음을 확인할 수 있습니다.또 다른 관심 분야는 광대한(PPP가 성공적으로 협상되고 인증되었는지 여부)입니다.Vast가 UP인 경우 PPP가 성공적으로 협상 및 인증되었으며 Why can I access some web page with PPPoE but not other(PPPoE를 사용하여 일부 웹 페이지에 액세스할 수 있는 이유)로 진행할 수 있습니다.섹션을 참조하십시오.광주가 DOWN이면 다음 섹션을 계속 진행합니다.
어그리게이션 라우터에서 PPPoE 응답을 수신하고 있습니까?
활성 PPPoE 세션이 설정되지 않은 경우 debug vpdn pppoe-events 명령을 실행하여 PPPoE가 나타나지 않는 항목을 확인해야 합니다.
Router#debug vpdn pppoe-events *Mar 3 21:49:38.030: Sending PADI: vc=8/35 *Mar 3 21:49:38.030: padi timer expired *Mar 3 21:50:10.030: Sending PADI: vc=8/35 *Mar 3 21:50:10.030: padi timer expired *Mar 3 21:50:42.030: Sending PADI: vc=8/35 *Mar 3 21:50:42.030: padi timer expired *Mar 3 21:51:14.030: Sending PADI: vc=8/35 *Mar 3 21:51:14.030: padi timer expired *Mar 3 21:51:46.030: Sending PADI: vc=8/35 *Mar 3 21:51:46.030: padi timer expired Router#undebug all
이 예에서 Cisco DSL 라우터는 응답 없이 ISP에 PPPoE PADI(Active Discovery Initiation) 프레임을 지속적으로 전송합니다.PADI 프레임은 일련의 PPPoE 통화 설정 프레임 중 첫 번째 프레임입니다.ISP가 PADO(PPPoE Active Discovery Offer)로 응답하지 않으면 PPPoE 협상이 성공하지 못합니다.이 문제의 유일한 해결책은 ISP에 문의하는 것입니다.
PPPoE를 성공적으로 협상하면 debug vpdn pppoe-events 출력은 다음과 같습니다.
Router#debug vpdn pppoe-events *Mar 3 21:49:38.030: Sending PADI: vc=8/35 *Mar 3 21:50:10.030: PPPOE: we've got our pado and the pado timer went off *Mar 3 21:50:35.030: OUT PADR from PPPoE tunnel *Mar 3 21:50:50.030: IN PADS from PPPoE tunnel Router#undebug all
PPPoE가 성공적으로 협상된 경우 PPP 문제 해결에 대한 다음 섹션을 계속 진행합니다.
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이지만 모든 옵션일 수 있습니다.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 TAC에 문의해야 할 수 있습니다.
인증 실패
ISP에서 PPP 사용자 이름 또는 비밀번호를 인증할 수 없을 때 인증 오류가 발생합니다.이러한 상황이 발생할 수 있는 두 가지 시나리오가 있습니다.첫 번째 시나리오는 라우터를 제대로 구성하지 않을 때 발생하는 인증 유형 불일치입니다.PAP 및 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 !--- Turn off ppp debug
두 인증 불일치 문제를 모두 수정하려면 적절한 PPPoA 구현 옵션 컨피그레이션을 참조하고 PPP 인증을 다시 구성하십시오.
두 번째 인증 문제 시나리오는 잘못된 PAP 사용자 이름 또는 비밀번호입니다.이것이 문제인지 확인하려면 디버그 ppp 협상 명령을 실행합니다.라우터가 CHAP(Challenge Handshake Authentication Protocol)와 PAP(Password Authentication Protocol)에 모두 구성되어 있다고 가정할 때, 이 가이드의 앞에서 설명한 컨피그레이션에 따라 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
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
PPPoE는 사용할 수 있지만 다른 웹 페이지는 액세스할 수 없는 이유는 무엇입니까?
라우터에서 PPPoE 클라이언트를 실행할 때 일부 웹 페이지에만 액세스하는 것은 일반적인 문제입니다.PPPoE는 설계에 따라 최대 1492바이트의 MTU를 지원할 수 있습니다.따라서 최종 디바이스가 1492바이트보다 크지 않은 프레임을 전송하도록 해야 합니다.대부분의 PC와 최종 사용자 워크스테이션의 기본 MTU는 1500바이트이므로 MTU를 1492바이트로 제한하는 것은 문제가 될 수 있습니다.
MTU 크기를 조정하는 두 가지 옵션이 있습니다.라우터에서 MTU 크기를 조정하고 PC에서 MTU 크기를 조정합니다.
Cisco DSL 라우터에서 PPPoE MTU 크기 조정
중요 참고 사항:
이러한 컨피그레이션 명령은 Cisco DSL 라우터에서 NAT(Network Address Translation) 또는 PAT(Port Address Translation)를 실행하는 경우에만 작동합니다.
Cisco IOS® Software Release 12.2(2)XH의 ip adjust-mss 명령이 ip tcp adjust-mss <mss value>로 변경되었습니다.이 변경 사항은 Cisco 800 Series 라우터 및 Cisco 820 Series Routers for Cisco IOS Release 12.2(2)XH의 릴리스 노트에 설명되어 있습니다.
!
vpdn enable
no vpdn logging
!
vpdn-group pppoe
request-dialin
protocol pppoe
!
interface ethernet0
no shut
ip address <ip address> <subnet mask>
ip adjust-mss 1452
!--- The TCP MSS command requires an MSS of 1452, not 1492.
ip nat inside
no ip directed-broadcast
!
interface atm0
no shut
no ip address
no ip directed-broadcast
no atm ilmi-keepalive
bundle-enable
!
interface atm0.1 point-to-point
no ip directed-broadcast
pvc <vpi/vci>
pppoe-client dial-pool-number 1
!
!
interface dialer1
ip address negotiated
mtu 1492
ip nat outside
encapsulation ppp
dialer pool 1
ppp chap hostname <username>
ppp chap password <password>
ppp pap sent-username <username> password <password>
!
ip nat inside source list 1 interface dialer1 overload
!
ip classless
ip route 0.0.0.0 0.0.0.0 dialer1
access-list 1 permit
0.0.255.255
!
DR TCP 유틸리티를 사용하여 PC에서 PPPoE MTU 크기 조정
PC의 MTU 크기를 변경하려면 다음 단계를 완료하십시오.프로시저가 완료되면 레지스트리 변경 내용이 저장됩니다.
참고: Dr. TCP 유틸리티는 모든 Windows 기반 PC와 호환됩니다.
-
Dr. TCP 유틸리티의 최신 버전을 다운로드합니다
. -
브라우저 페이지를 새로 고쳐 페이지가 최신 상태인지 확인합니다.
-
Dr.TCP 유틸리티를 실행합니다.
-
메뉴에서 이더넷 어댑터를 선택합니다.
-
MTU 필드에 1492를 입력합니다.
-
Apply(적용)를 클릭하여 변경 사항을 저장한 다음 Exit(종료)를 클릭합니다.
-
PPPoE PC 클라이언트를 재부팅합니다.
.PPPoE 클라이언트 PC당 한 번만 유틸리티를 실행해야 합니다.
추가 MTU 문제 해결 단계
Dr. TCP 또는 Cisco DSL 라우터에서 MTU 크기를 변경해도 특정 웹 사이트를 탐색할 수 없는 경우 MTU 크기를 다시 조정합니다.Dr TCP에서 MTU 크기를 1452로 변경하거나 Cisco DSL 라우터의 MSS 조정 값을 1412로 변경합니다.이러한 크기가 너무 크면 Dr TCP의 경우 1400을, Cisco DSL 라우터의 경우 MSS의 경우 1360을 조정할 때까지 MTU 크기를 계속 줄이십시오.
피드백